This agreement forms part of our builder terms. It applies when we host a DVM for you on dvmkit Cloud and, in doing so, handle personal data on your behalf. You accept it when you accept the builder terms, and there is nothing separate to sign.
It is written to meet Article 28 of the UK GDPR and, where they apply to you, the EU GDPR and the US state privacy laws covered in section 11. Terms such as "controller", "processor", "personal data" and "personal data breach" have the meanings those laws give them. "We", "us" and "our" mean DVM Technologies Ltd, "you" has the meaning the builder terms give it, and "your DVM" means a DVM we host for you.
1. Who does what
You are the controller of the personal data your DVM handles. If you run your DVM on behalf of someone else who is the controller, you are their processor, and we are your sub-processor.
We are your processor. We handle that personal data only to host your DVM for you.
What this agreement covers. We call the personal data it covers "job data". It is personal data in anything your DVM receives, stores, produces or records while we host it: the requests callers send it and its responses as they pass through our router, its database, its logs, the traces and error reports it sends to our platform, and backups of any of these.
What it does not cover:
- personal data we handle as a controller for our own purposes. That includes your account and billing details, the records our router and platform keep to route traffic and keep the platform secure, the operational data described in section 10 of the builder terms, and feedback that callers send us about your DVM. Our privacy policy covers all of it;
- DVMs you run on your own infrastructure;
- services your DVM calls, such as model APIs. They are your processors, not our sub-processors.
2. Details of the processing
| What | Detail |
|---|---|
| Subject matter | Hosting your DVM on dvmkit Cloud |
| Nature | Building and running your code, routing requests to it, and storing, backing up and deleting its data |
| Purpose | Providing the platform to you under the builder terms |
| Duration | For as long as we host your DVM, and then until its data is deleted under section 8 |
| Data subjects | Your DVM's callers, and anyone whose personal data appears in the jobs it handles |
| Personal data | Whatever your DVM receives, produces or records. Typically: job inputs and results, such as text, audio, images, documents and web addresses; caller identifiers, such as public keys and payment addresses; and IP addresses and request details in logs |
| Special category data | None is needed to use the platform. Section 7 covers what happens if your DVM handles it |
3. Your instructions
We process job data only on your documented instructions. Your instructions are the builder terms and this agreement, the code you deploy, and the settings you choose through dvmctl and the dashboard, such as your DVM's configuration, secrets and retention period. Any other instruction must be agreed with us in writing.
If we believe an instruction breaks data protection law, we will tell you. If the law requires us to process job data in some other way, we will tell you before we do, unless the law prevents us from telling you.
4. Our commitments
Confidentiality. Everyone we authorise to access job data is bound to keep it confidential.
Access only when needed. We do not read job content in the ordinary course of running the platform. We access your DVM's data only to keep the platform running, to fix a problem, to investigate abuse or a security incident, or to comply with the law.
Security. We take the technical and organisational measures listed in Annex 2, and we will not reduce the overall protection they give while this agreement lasts.
No other use. We do not sell job data, use it for advertising, or use it to train or improve AI models.
Requests from individuals. You can find, correct, export and delete your DVM's data yourself, through dvmctl. If an individual asks us about data your DVM holds, we will pass the request to you, and we will not answer it ourselves unless the law requires us to.
Other help. Taking into account the nature of the processing and the information we have, we will help you meet your obligations to keep personal data secure, to notify breaches, to carry out data protection impact assessments and to consult regulators. That help mostly takes the form of information about how the platform works. If you need more than that, we will agree a reasonable charge with you in advance.
5. Sub-processors
You authorise us to use the sub-processors listed in Annex 1.
Before we add or replace a sub-processor that will handle job data, we will email you at least 7 days in advance, saying who it is, where it is and what it will do. If you object on reasonable data protection grounds within that time, we will work with you to resolve it. If we cannot, you may end the builder terms before the change takes effect, and we will refund any fees you have paid for time after that.
If we have to replace a sub-processor urgently, for example because it has failed, we may do so straight away and will tell you as soon as we can. You can still object, and end the builder terms, in the same way.
We require each sub-processor to protect job data at least as well, in substance, as this agreement does, and we remain responsible to you for what they do.
6. Personal data breaches
If we become aware of a personal data breach affecting job data, we will tell you without undue delay, at the email address on your account. We will tell you what we know about what happened, which data and callers are likely to be affected, and what we are doing about it, and we will keep you updated as we learn more. Telling you about a breach is not an admission of fault.
7. Your commitments
- You have a lawful basis for the processing, and your instructions to us comply with data protection law.
- You tell callers how your DVM uses their personal data, including which of your providers receive it.
- You decide how long your DVM keeps job content. The SDK default is 730 days after a job reaches a final status. You can set
jobRetentionDaysto a shorter or longer whole number of days, or to0to disable automatic age expiry. Reads do not renew that period. A support or dispute hold retains the affected job until explicitly cleared; a review date, including an overdue one, does not end it. You record the reason and review the continuing need. Expiring content does not remove durable outcome, financial, and signed receipt evidence under their separate retention rules. - The platform is not designed for special category data, such as health information, or for criminal offence data. If your DVM handles either, you are responsible for deciding that the measures in Annex 2 are appropriate for it, and for any assessment the law requires.
- You keep your code, its dependencies, your keys and your secrets secure.
8. Deletion
You can export your DVM's data before deletion or the end of the builder terms by connecting with dvmctl db connect, or by using dvmctl db proxy with a PostgreSQL client.
If you want to keep financial evidence after destruction, save and verify a minimized financial export using the SQL recipe supplied with the service's SDK before either dvmctl destroy variant. It preserves signed receipts, amounts, currencies, financial links, and recovery outcomes, and excludes raw job input and output, bearer proofs, and operational credentials. You keep the export securely under your own retention policy. Our separate platform financial history does not replace it.
Export while the service and database are available. --keep-db keeps database storage; it still removes the application and its database tunnel. Use the same owning organisation for the database and destruction commands.
When you delete a DVM, we delete its application and its database straight away, unless you ask us to keep the database. Copies in our hosting provider's backups, and in logs and traces, are deleted as they expire, which takes no more than 90 days. A DVM that holds caller balances is deleted only after the 30-day reclaim period in section 6 of the builder terms.
When a free trial ends, you have 7 days to export the DVM's data or buy a plan, as section 4 of the builder terms describes. If you do neither, we then delete its application and its database. Backups, logs and traces expire as they do when you delete a DVM, and a DVM that holds caller balances is deleted only after the reclaim period.
When the builder terms end, we delete the data of all your DVMs in the same way, 30 days after the end, unless you ask us to do it sooner.
After deletion we keep no job data, except where the law requires us to keep it.
9. Information and audits
We will make available the information you reasonably need to show that we meet this agreement, including answers to reasonable security questionnaires. If that information is not enough, or a regulator requires it, you or an independent auditor bound by confidentiality may audit our compliance. Audits take place no more than once a year, on at least 30 days' notice and at your own cost, and must not disrupt the platform or expose other builders' data.
10. International transfers
Your DVM runs in the United States, in our hosting provider's Ashburn, Virginia region, and the parts of our platform that handle job data run there too.
Where job data subject to the UK GDPR leaves the UK, we rely on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, or on adequacy regulations where they apply. Where job data is subject to the EU GDPR, transfers from the EU to us rely on the European Commission's adequacy decision for the UK, and onward transfers to sub-processors outside the UK and the EU rely on the EU Standard Contractual Clauses or on an adequacy decision.
11. United States privacy laws
Where a US state privacy law applies to job data, such as the California Consumer Privacy Act, we act as your service provider or processor under that law. We process job data only for the business purpose in section 2: hosting your DVM for you. Unless that law allows it, we do not:
- sell or share job data;
- keep, use or disclose it for any other purpose, or outside our relationship with you;
- combine it with personal data from any other source.
We will meet the obligations that law places on us, and tell you if we can no longer do so. You may take reasonable steps to stop and put right any use of job data that breaks this section.
12. Liability
Our liability under this agreement is subject to the limits and exclusions in section 12 of the builder terms, to the extent data protection law allows. Nothing in this agreement limits anyone's liability to individuals under data protection law.
13. Changes and precedence
We may update this agreement. If a change materially reduces the protection it gives job data, we will email you at least 7 days before it takes effect, and section 13 of the builder terms applies. Changes the law requires, such as adopting a new transfer mechanism, take effect with as much notice as the law allows. Any other change takes effect as soon as we publish it.
If this agreement conflicts with the builder terms about personal data, this agreement applies. Where Standard Contractual Clauses or the UK Addendum apply to a transfer, they take precedence over both for that transfer.
Annex 1. Sub-processors
| Sub-processor | Where | What it does |
|---|---|---|
| Fly.io, Inc. | United States (Ashburn, Virginia region) | Builds and runs your DVM; hosts its database and the backups of it; runs our router, which passes requests to your DVM; keeps your DVM's logs; and hosts our platform database, where the traces and error reports your DVM sends us are kept |
Fly.io uses sub-processors of its own, which it lists at fly.io/legal/sub-processors. They include AI providers that Fly.io uses for log analysis and support.
Annex 2. Security measures
- Encryption in transit. Callers reach your DVM over HTTPS, and our router connects to it over HTTPS. The router refuses to connect to a DVM any other way.
- Encryption at rest. Your DVM's database is stored on volumes that our hosting provider encrypts at rest.
- Isolation. Each DVM runs in a container as its own application, on its own virtual machines, with its own database and credentials.
- Secrets. Secrets you set through the platform are held as encrypted secrets by our hosting provider and are not written into your DVM's image.
- Access control. Access to production systems is restricted to the people who need it.
- Accounts. No passwords are stored; sign-in is by a one-time emailed link or a verified GitHub or Google identity. Each
dvmctlsign-in is approved in the browser, and creates an API key you can revoke from the dashboard. - Backups. Your DVM's database is backed up daily, and each backup expires after a limited period.
- Deletion. Deleting a DVM deletes its application and, unless you ask otherwise, its database.
- Monitoring and reports. We monitor the platform's health and alert on failures, and we accept vulnerability reports at security@dvmkit.com.