Legal
Privacy notice
Last updated 9 October 2026
This notice covers the Salpa desktop application, Salpa Compute, and the salpa.app website. It is written to be read, and every statement in it is checked against what the software actually does.
Who is responsible
BoCo Research B.V., Leiden, the Netherlands (Chamber of Commerce / KvK 89932056), of which BoundaryComputing is a registered name. For anything in this notice, write to hello@salpa.app.
The short version
- Salpa runs on your computer. Your workflows, data and results stay on your machine unless you deliberately run a cloud node.
- Salpa Compute needs an account (Google or email). We keep your account details and a record of each cloud job — what ran, when, for how long, at what cost — but not the contents of your inputs or results. The one exception: a result too large to send back directly waits in Google Cloud Storage until your app has downloaded it, and is deleted then, or after 24 hours at the latest.
- Your job data is processed on infrastructure run by Google Cloud (Belgium and the USA) and Modal (USA) for the duration of the job, and not kept by us.
- The assistant is in early access, for invited accounts only. When you use it, your messages and what it reads of your project, with full paths replaced, go through our gateway to Google Cloud’s Vertex AI, which runs the model. We keep a record of each request (its size, cost and timing), not its text.
- The copilot is off by default and only sends anything anywhere if you turn it on and configure a model provider.
- No analytics, no cookies — not in the app, not on this website.
- We do not sell data, we show no advertising, and we do not use your content to train models.
The Salpa desktop application
Salpa is a desktop application. The workflow engine, the job queue and the worker all run locally; your projects, workflows, node inputs and results are stored in files and a local database on your computer, and the application’s own log files stay there too. We have no access to any of it.
The application does connect to the internet for a few specific things:
- Installing node environments. When a node needs software, the app downloads packages from public repositories (conda-forge, PyPI, GitHub). Those services see the ordinary technical data of a download, such as your IP address.
- Salpa Hub. The package registry and the packages you install are fetched from GitHub (the public
BoundaryComputing/salpa-hubrepository). - What’s new. The app fetches a small news feed from salpa.app, which is hosted by Google (Firebase Hosting).
- Usage statistics: none. The app sends none. Builds up to and including 0.2.3 reported anonymous usage events — the app being opened, screens being viewed — to Google Analytics with a random installation identifier (never your account details, workflows or data). That code was removed in 0.3.0; if you are on an earlier build, updating stops it.
- Signing in and cloud nodes — see Salpa Compute below.
- The copilot — see below.
The application does not update itself and does not send crash reports. Downloads of the application itself come from GitHub Releases, so GitHub sees the download.
Salpa Compute
Your account
Salpa Compute lets you run selected AI models as cloud nodes, on hardware we run, instead of on your own machine. It requires an account, which you create in the app with an email address and password or with a Google account. Sign-in is handled by Firebase Authentication, a Google service: Google stores your email address, a password hash (we never see the password), or the identity Google provides for you (name, email address and profile picture), and sends verification and password-reset emails on our behalf.
The first time you run a cloud node we create an account record: your user ID, email address and display name, when the account was created, your plan and quota (the free tier, one GPU-hour a month, unless your account was invited to early access), and account settings. We may email you about your account or the service; we do not send marketing.
Each cloud job
For every cloud node you run we record:
- a job identifier, your user ID and email address;
- which node and which service ran it, and on which backend (Modal or Google Cloud);
- status, start and finish times, duration, GPU and CPU seconds, and the computed cost;
- if the job failed, the error message;
- whether the job was stopped, and when; and a one-way hash of the random identifier your app gives each run, which is what lets it stop the run. While a GPU job runs we also note that it is in progress, which is how an account is kept to two GPU jobs at a time;
- the node’s package and version, and how the result was returned; for a result held for download, its size, its checksum, and when it was stored and deleted;
- an input summary: the names of the input fields the node received (for example
sequence), not their contents.
We do not store your inputs, and we hold a result only until your app has fetched it. The data a node sends — sequences, structures, ligands, parameters — travels from your app to our API gateway and on to the compute service, which works on it in a folder of its own and deletes that folder when the job ends. The result normally comes straight back to your app. A result too large for that (so far, some Boltz-2 predictions) is uploaded by the compute service to a private Google Cloud Storage bucket. Your app downloads it over a link that only it receives and that expires within an hour, and has it deleted as soon as it is saved. A result that is never downloaded is deleted within 24 hours. The infrastructure providers keep ordinary operational logs of requests for a limited time under their own terms.
One node option sends data somewhere else. With MSA mode server, the Boltz-2 service sends your protein sequences to the public ColabFold MSA server (api.colabfold.com) to build the multiple sequence alignment. That server is run by the ColabFold team, not by us or by Modal, under its own terms. Choose MSA mode empty or provided to keep your sequences off it.
Where this happens
- Account and job records: Google Cloud Firestore, multi-region
eur3— Belgium and the Netherlands. - API gateway (the hop every cloud job passes through): Google Cloud Run, region us-central1, Iowa, USA.
- Boltz-2, Chai-1 and DiffDock: Modal (Modal Labs, Inc.), USA.
- Evo2: Google Cloud Run, region europe-west1, Belgium.
- ProteinMPNN: Google Cloud Run, region us-central1, Iowa, USA.
- A large result waiting to be downloaded: Google Cloud Storage, region us-central1, Iowa, USA, for 24 hours at most.
So your account records stay in the EU, but the data you submit to a cloud node passes through the United States, and for Boltz-2, Chai-1, DiffDock and ProteinMPNN is processed there. Google LLC is certified under the EU-U.S. Data Privacy Framework and processes data for us under the Google Cloud Data Processing Addendum; Modal processes data for us under its Data Processing Addendum, which incorporates the EU Standard Contractual Clauses. If you would rather your data not leave the EU, run the node locally instead — every cloud node is optional.
How long we keep it
Account and job records are kept for as long as your account exists. If you ask us to delete your account, we delete it and its records within 30 days, except what we must keep for accounting. There is not yet a self-service delete button — email hello@salpa.app from the address on the account.
The assistant (early access)
Accounts in our early-access programme can use an assistant beside a project in the app. It is a test: we invite the people who use it, and it may change or stop.
What it sends
When you write to the assistant, the app sends:
- your message and the earlier messages of the same conversation, as you wrote them;
- where you are in the app: the project’s page or a workflow’s canvas, which workflow is on screen, and which are open in tabs;
- what the assistant reads to answer you: the project’s name and description and the name of its folder; the workflows it opens, which can be any of yours, not only this project’s, with their steps, settings and runs; a step’s results, log lines and errors; text files it opens in a workflow’s folder; the documentation and workflow templates of the installed packages; a summary of a PDB entry; the outcome of the steps it prepares and of the changes you apply, including an error the canvas reports; which packages are installed; Salpa’s version; and your account’s assistant allowance and whether the assistant is on for it.
In everything the assistant reads, the app replaces full paths before sending them: your home folder becomes ~, the project’s and its workflows’ folders become placeholders, and so do the folders of any other full path, so where your files sit on your computer stays there. What you type is sent as you wrote it.
It goes from your computer to our API gateway, which runs in Google Cloud’s us-central1 region in the United States, and on to Google Cloud’s Vertex AI, which runs the model, GLM-5.2. The model is served from Google’s global endpoint, so where it is processed is not pinned to a region and may be outside the EU. One message can take up to eight requests to the model, each sending the conversation so far. Your sign-in token goes with each request to our gateway, which uses it to know your account and check its allowance; it is not passed to Vertex AI. Google states that it does not use prompts and responses to train models and does not share them with third parties, including the model’s publisher. GLM-5.2 is a preview offering on Vertex AI.
When the assistant looks up a protein’s PDB entry, your app asks the RCSB Protein Data Bank (data.rcsb.org) for its public record, as Salpa’s own nodes do when they download an entry.
When the assistant looks up a tool in Salpa’s tool database, our private record of the tools Salpa’s packages run and their known errors, your app sends our API gateway the tool’s name or the phrase it searches for, such as an error message, with your sign-in token. The answer comes from that database, not from the model.
If Salpa Library is open for your account, the assistant can also search it: our private collection of nodes that we checked by running them. A search sends our API gateway what the assistant asks for (a file format, a role such as a trajectory, input or output, a tool’s name or a package’s name) with your sign-in token, and the answer comes from the library’s index, not from the model. When you apply a card to install a package from it, your app sends the package’s name and version and the one line on the card saying what you are working on; the package’s files come back from our gateway and are installed on your computer like any other package. When the assistant reads one of the library’s workflow templates, your app fetches it from our gateway by its identifier.
What we keep
For each request to the model we keep a record that includes your user ID, a request identifier, the model and the version of the assistant’s instructions, when it started and ended, the number of tokens sent and received, the cost, how it ended, and what was held and charged against your allowance. We do not keep the text of your messages or of the assistant’s replies. These records are kept, and deleted when you ask, like your account’s other records above. Google Cloud keeps ordinary operational logs of the requests for a limited time under its own terms. The conversation itself, and a record of what the assistant read and did, stay on your computer: in Salpa’s own records and in your project’s folder.
For each lookup in the tool database we keep a count of your lookups in that hour, for a limit of 120, deleted about two days later, and a log line, kept 30 days, with the tool’s or package’s name, the kind of lookup, whether it was answered, the answer’s length, that hour’s count and a code derived from your user ID. We do not keep the phrase or the answer.
For Salpa Library we keep a count of your searches and of your deliveries in each hour, for limits of 120 searches and 10 packages or templates, deleted about two days later, and a log line for each call, kept 30 days, with the package’s name and version or the template’s, how the call ended, the size of the answer, that hour’s count and a code derived from your user ID. Of a search we keep a package’s name only when you searched by a name the library holds, and nothing else of what was asked. Of the line saying what you are working on we keep its length and a code computed from it with a key we hold, so that a line you show us can be checked against the log; we do not keep its words.
What you send us
A thumbs-up or thumbs-down on a reply sends which conversation, which reply and which way, with your user ID, the assistant’s version and the time; no text.
If you choose Send this conversation, the app first shows you what it will send, with the full text a click away, and a box for a note. What leaves is what you were shown, plus your note, and nothing else: the app checks this before it sends. It is the conversation as Salpa recorded it on your computer:
- your messages and the assistant’s replies, the reasoning the model wrote, any error a reply met, and the time of each step;
- each tool the assistant used, what it asked of it and what it returned, which can include the project’s name, description and folder name, workflows with their settings and runs, steps’ results, logs and errors, text files it opened, documentation, PDB summaries and your remaining allowance;
- the thumbs you gave in it, and the identifiers of its earlier sends, if any;
- the record of the conversation’s events: token counts, the model’s request identifiers, workflow and template identifiers, and the names of workflow folders;
- Salpa’s and the assistant’s versions, and your note.
Before it is sent, full paths are replaced everywhere in it as described above, in your own messages too; the note is sent as you write it.
It goes through our gateway to a private Google Cloud Storage bucket in the us-central1 region (United States), with an index entry in our database that holds your user ID, the conversation’s identifier, where it is stored, its size and checksum, the versions and the time, and none of its text. A thumb is kept in the same database as the entry described above. Only the Salpa team can read them. We read what you send to improve the assistant and keep it as a test case; we do not use it to train a model.
Both are kept, with no expiry, until you ask us to delete them. Write to hello@salpa.app with the identifier the app showed you when you sent a conversation (its Ask us to delete it link writes that email for you), or from your account’s email address to cover everything you sent, thumbs included, and we delete it: a conversation leaves the bucket at once, with its index entry.
The copilot
The app includes an assistant. It is off by default. If you enable it in Settings, your messages to it — together with the workflow or project you are looking at, which is the context it needs to help — are sent to the language-model provider configured in the app. The copilot works only with credentials you provide yourself; the supported providers are Google (Gemini via Vertex AI), OpenAI, Anthropic, and Ollama for a model running on your own machine. With Ollama, nothing leaves your computer. Whichever provider you choose, its own terms and privacy notice apply to what you send it.
The copilot’s memory of past interactions is stored in the app’s data folder on your computer, not with us.
The salpa.app website
salpa.app is a static site hosted by Google (Firebase Hosting), which processes the technical data of each request — such as your IP address and browser type — to serve and secure it. The site sets no cookies and runs no analytics (it used Google Analytics until 1 September 2026; that is gone). The documentation search runs entirely in your browser. There are no accounts and no forms on the site; if you email us, we keep the correspondence as long as we need it to handle the conversation, and we do not add you to any list.
Who processes data for us
- Google — Firebase Authentication, Firestore, Cloud Run, Cloud Storage, Firebase Hosting, and Vertex AI for the assistant’s model (early-access accounts only) (Google LLC, USA; EU-U.S. Data Privacy Framework and Cloud Data Processing Addendum with Standard Contractual Clauses).
- Modal Labs, Inc. — GPU compute for Boltz-2, Chai-1 and DiffDock (USA; Data Processing Addendum with Standard Contractual Clauses).
- GitHub — application downloads and Salpa Hub packages.
- Package repositories (conda-forge, PyPI) — node environment downloads.
- Your model provider — only if you enable the copilot and configure one.
- The ColabFold MSA server — only if you choose MSA mode
serverfor Boltz-2.
Nobody else. We do not sell or rent data, and we do not share it for advertising.
Why we are allowed to
Under the GDPR we process account and job data to provide the service you signed up for (performance of a contract), and quota enforcement, abuse prevention and the technical data of requests on the basis of our legitimate interest in running a working, fair and secure service. The assistant’s requests are processed to provide the early-access service your account was invited to (performance of a contract). Anything you send to a language-model provider through the copilot, you send by choosing to turn it on.
Your rights
You can ask what we hold about you, have it corrected or deleted, receive a copy, or object to its use. Email hello@salpa.app and we will act on it. You can also complain to the Dutch supervisory authority, the Autoriteit Persoonsgegevens.
Age
Salpa Compute accounts are for people aged 16 and over.
Changes
When this notice changes, the date at the top changes with it, and the app’s “what’s new” feed says so. The current version is always at salpa.app/privacy.