Glac Data Processing Agreement

Last updated: 28 October 2026.

1. Parties and how this DPA applies

1.1 This Data Processing Agreement (“DPA”) is between GLAC PTY LTD, a company registered in Australia (ACN 680 390 130, ABN 27 680 390 130, registered address 5 Kalimna Ave, Campbelltown SA 5074, Australia) (“we”, “us”), and the customer that has accepted the Glac Terms of Service (“you”).

1.2 This DPA is part of the agreement between us made up of the Terms of Service, the pricing page and this DPA (the “Agreement”). It applies automatically whenever Data Protection Laws apply to our processing of Customer Personal Data, from the moment you accept the Terms of Service; you do not need to sign it.

1.3 If this DPA conflicts with the Terms of Service, this DPA wins on the processing of Customer Personal Data. If the Standard Contractual Clauses apply and conflict with this DPA, the Standard Contractual Clauses win.

2. Definitions

• Data Protection Laws: the laws on personal data that apply to the processing under this DPA, as far as each applies: the EU General Data Protection Regulation 2016/679 (“GDPR”); the UK GDPR and the UK Data Protection Act 2018; the Swiss Federal Act on Data Protection (“FADP”); the Australian Privacy Act 1988; Singapore’s Personal Data Protection Act 2012; and the privacy laws of US states, such as the California Consumer Privacy Act (“US State Privacy Laws”).
• Customer Content: everything that you, your members or your users put into or run on the Service, as defined in the Terms of Service.
• Customer Personal Data: personal data in Customer Content that we process for you.
• Sub-processor: a third party that we engage to process Customer Personal Data.
• Security Incident: a breach of our security that leads to the accidental or unlawful destruction, loss or alteration of, or unauthorized disclosure of or access to, Customer Personal Data.
• Standard Contractual Clauses: the standard contractual clauses for the transfer of personal data to third countries in the Annex to European Commission Implementing Decision (EU) 2021/914 of 4 June 2021. UK Addendum: the International Data Transfer Addendum to them, version B1.0, issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018.
• Region, Sandbox, App, Volume, Snapshot, Backup, Logs, Project and Account have the meanings in the Terms of Service.
• “Controller”, “processor”, “data subject”, “personal data” and “processing” have the meanings in the GDPR.

3. Roles and scope

3.1 You are the controller of Customer Personal Data, or a processor acting for your own customers. We are your processor, or your sub-processor.

3.2 We are a controller in our own right, not your processor, for the data we need to run our business: logins, Account and membership records, billing, payment and tax records, usage records, audit records and security logs. Our Privacy Policy describes that processing. This DPA does not cover it.

3.3 Annex I describes the processing that this DPA covers.

4. Your instructions

4.1 We process Customer Personal Data only on your documented instructions. Your instructions are:

• (a) the Agreement;
• (b) what you set in the Service through the API, the console, the command-line tool or the SDKs, for example the images and commands you run, the Regions you choose, egress rules, how Logs are kept (whether instance output is kept, whether it is kept long-term, how many request lines are kept, whether failed requests are always kept), Log export endpoints, webhooks, Backup rules, deletion times, the Project’s delete_after_idle_days, and every deletion you make;
• (c) any other written instructions that we agree to.

4.2 We may process Customer Personal Data otherwise only where the law requires it. If so, we tell you before we do, unless the law forbids that.

4.3 We tell you if we believe that an instruction infringes Data Protection Laws.

4.4 You are responsible for the lawfulness of your instructions, for having a legal basis for the processing, and for giving data subjects the information the law requires. If you put special categories of personal data into the Service, you are responsible for deciding that the measures in Annex II are appropriate for them.

5. Our people

5.1 Everyone we authorize to process Customer Personal Data is bound by a duty of confidentiality.

5.2 Our staff access Customer Content only when you ask us to for support, when it is needed to keep the Service running or secure or to investigate abuse, or when the law requires it.

5.3 [Drafting note — remove before publishing: reads of an App’s Logs by our operators, through the control plane or directly on a node, are not yet recorded in the Project’s audit log (control/README.md, 应用的日志, 还没有的). Do not promise that every staff access is logged until it is.]

6. Sub-processors

6.1 You authorize us to engage the Sub-processors listed in Annex III and on https://glac.ai/subprocessors.

6.2 We tell you at least 14 days before we add or replace a Sub-processor, by email to the Account’s email address and by updating that list. You may object, on reasonable grounds relating to data protection, within that period. We will then work with you in good faith to find a solution. If we cannot, you may stop using the Service, delete your Customer Content and close your Account as Section 18.1 of the Terms of Service allows; Section 9.6 of the Terms of Service says what is refunded.

6.3 If a Sub-processor fails suddenly and we must replace it to keep the Service running, we tell you as soon as we can.

6.4 We impose on each Sub-processor, by written contract, data protection obligations that protect Customer Personal Data at least as well as this DPA. We remain liable to you for our Sub-processors’ performance of those obligations.

7. Security

7.1 We implement the technical and organizational measures in Annex II.

7.2 We may change those measures, but not in a way that lowers the overall protection of Customer Personal Data.

7.3 Some security depends on you. You are responsible for keeping your API keys, tokens and passwords secret; for the security of the software you run, which in our default image runs as root inside the Sandbox; for egress rules, including the hosts you allow each secret to go to; for encrypting data inside your Sandboxes if you need more than Annex II gives; for keeping your own copies of data you cannot lose; and for not putting personal data into resource names, metadata labels or other fields not meant for it.

8. Security Incidents

8.1 We notify you without undue delay, and in any case within 72 hours, after we become aware of a Security Incident.

8.2 We send the notice to the Account’s email address[ and to its owners]. It describes, as far as we know at the time: what happened; the categories and approximate number of data subjects and records concerned; the likely consequences; what we have done and propose to do; and whom to contact. We send further information as we learn it.

8.3 We take reasonable steps to contain the Security Incident and limit its effects, and we cooperate with you so that you can meet your own obligations.

8.4 Notifying you of a Security Incident is not an admission of fault or liability.

9. Help with your obligations

9.1 Requests from data subjects. You can read, change and delete Customer Content yourself through the Service: files and commands in Sandboxes, Volumes, Snapshots, Backups, Apps and Logs, including deleting the Logs of an App before a chosen time. If a data subject writes to us about Customer Personal Data, we pass the request to you and do not answer it ourselves unless you ask us to. If you cannot meet a request with the Service’s own tools, we help you as far as is reasonable.

9.2 Assessments. We give you reasonable help with data protection impact assessments and consultations with a supervisory authority about the Service, as far as they concern our processing[, at your cost where the help goes beyond providing documents we already have].

9.3 Records. We keep the records of processing that Data Protection Laws require of a processor.

10. Where we process, and international transfers

10.1 We run the Service in three Regions: North America (na), Europe (eu) and Asia-Pacific (ap), on servers in [countries for each Region]. Our control plane runs in [control-plane country], with a standby copy in [standby country].

10.2 You choose the Region of a Sandbox, a Volume or an App. You should know that:

• (a) a Sandbox or Volume created without a Region goes to the control plane’s Region, and an App created without Regions runs in all of them;
• (b) if the chosen Region cannot take a new Sandbox at that moment, the Service creates it in the nearest other Region that can, unless it must go to a particular host (for example, to use a Snapshot or a Volume that is there);
• (c) if a host fails, the Service may continue a Sandbox on another host, which may be in another Region;
• (d) Logs are kept in object storage at the site of the node that wrote them, and they are decrypted on the control plane’s machine when you read them;
• (e) the Sub-processors in Annex III process data in the locations listed there.

[Drafting note — remove before publishing: there is no setting today that keeps a Sandbox in one Region in every case (control/README.md, 区域). Do not offer a data-residency promise until there is one.]

10.3 Transfers from the European Economic Area. We are in Australia, which has no adequacy decision. Where Customer Personal Data is transferred to us from the European Economic Area, the Standard Contractual Clauses are incorporated into this DPA by reference and apply, with you as the data exporter and us as the data importer, as follows:

• (a) Module Two (controller to processor) applies where you are a controller, and Module Three (processor to processor) where you are a processor acting for your own customers.
• (b) Clause 7 (docking clause) applies.
• (c) In Clause 9(a), Option 2 (general written authorization) applies, and the time for telling you about a change of Sub-processor is the one in Section 6.2.
• (d) In Clause 11(a), the optional wording does not apply.
• (e) In Clause 13(a) and Annex I.C, the competent supervisory authority is the one that Clause 13(a) designates for your situation.
• (f) In Clause 17, Option 1 applies, and the governing law is the law of Ireland.
• (g) In Clause 18(b), the courts are the courts of Ireland.
• (h) Annexes I, II and III of the Standard Contractual Clauses are completed by Annexes I, II and III of this DPA.
• (i) The audits under Clause 8.9 are carried out as Section 11 says, and the certification of deletion under Clauses 8.5 and 16(d) is given when you ask for it (Section 12.7).

10.4 Transfers from the United Kingdom. For transfers of Customer Personal Data to us from the United Kingdom, the UK Addendum is incorporated into this DPA and applies with these entries: in Table 1, the parties as in Annex I; in Table 2, the Standard Contractual Clauses with the modules and options in Section 10.3; in Table 3, Annexes I, II and III of this DPA; in Table 4, neither party may end the UK Addendum under its Section 19. Part 2 consists of the Mandatory Clauses of the Approved Addendum, being the template Addendum B1.0 issued by the ICO and laid before Parliament in accordance with section 119A of the Data Protection Act 2018 on 2 February 2022, as it is revised under Section 18 of those Mandatory Clauses.

10.5 Transfers from Switzerland. For transfers of Customer Personal Data to us from Switzerland, the Standard Contractual Clauses apply as in Section 10.3, with the changes that the Swiss Federal Data Protection and Information Commissioner requires: where the FADP governs a transfer, references to the GDPR are to be read as references to the FADP, and the Commissioner is the competent supervisory authority, alongside the authority under Section 10.3(e) where the GDPR also applies; and “Member State” in Clause 18(c) is not to be read so as to stop data subjects in Switzerland from suing for their rights in Switzerland, where they habitually reside.

10.6 Onward transfers. We transfer Customer Personal Data to a Sub-processor in a country without an adequacy decision only under the Standard Contractual Clauses (Module Three, with the UK Addendum and the Swiss changes where they apply), or under another mechanism that Data Protection Laws allow, such as the EU–US Data Privacy Framework for a Sub-processor certified under it.

10.7 Requests from public authorities. If a public authority asks us for Customer Personal Data, we tell you unless the law forbids it, we check whether the request is lawful and challenge it if we conclude that it is not, and we disclose only what the request lawfully requires. For data transferred under the Standard Contractual Clauses, their Clause 15 sets out these duties in full.

10.8 If a transfer mechanism changes. If a mechanism in this Section is replaced or ruled invalid, or the European Commission adopts standard contractual clauses for importers that the GDPR applies to directly under its Article 3(2), we may change this Section to use the new mechanism, and we tell you as Section 15.2 says.

10.9 Other laws. Where the Australian Privacy Act 1988 applies to Customer Personal Data, before we disclose it to a Sub-processor outside Australia we take reasonable steps to make sure the Sub-processor handles it consistently with the Australian Privacy Principles (Australian Privacy Principle 8). Where Singapore’s Personal Data Protection Act 2012 applies, we meet the obligations it places on a data intermediary: we protect the data as Annex II describes, we keep it only as Section 12 describes, and we tell you without undue delay of a data breach. Section 13 deals with US State Privacy Laws.

11. Audits and information

11.1 We make available to you the information needed to show that we meet this DPA, including written answers to a reasonable security questionnaire [once a year].

11.2 Certifications. Today the Service has no third-party security certification or audit report. We plan to obtain SOC 2 and ISO/IEC 27001, and once we have the reports we make them available to you under a duty of confidentiality.

11.3 Audits. If the information in Section 11.1, and the reports in Section 11.2 once we have them, are not enough, or a supervisory authority requires it, you may audit our compliance with this DPA once in any 12 months, with at least [30] days’ notice, during business hours, through an independent auditor bound by confidentiality, and at your own cost. Audits do not include other customers’ data, or the premises of our hosting providers, which are covered by those providers’ own reports.

12. Deletion and return of Customer Personal Data

12.1 While the Agreement lasts. You can get Customer Content out through the Service at any time (files and command output from Sandboxes, Volumes, Snapshots, Backups and Logs) and delete it at any time.

12.2 What a deletion does.

• (a) Sandboxes, Volumes, Snapshots and Apps are removed from our hosts when you delete them. Copies of their disks and memory in object storage are removed by our clean-up process once a grace period of [one day] has passed, with two exceptions that the clean-up does not remove today: the batches in which a host stores small pieces of many disks together, which can hold pieces of the disks of deleted Sandboxes; and the finished images and memory of templates, including the template memory of App Versions, which holds the values of their environment variables and secrets. These stay in object storage, encrypted as Annex II describes, with no end date, and we do not use them for anything once what they belong to is deleted. When your Account is closed (Section 12.3) or its data is deleted for unpaid storage (Section 12.4), we destroy the encryption key of each of your projects as soon as that deletion has finished: from that moment, every copy that remains in object storage, these two kinds included, and the records of your things in our database cannot be read by anyone, us included. The key survives only inside our database backups, for at most 30 days that have a backup (Section 12.2(e)), and is used for nothing but restoring the Service after a failure of ours (Section 12.6).
• (b) A Backup leaves your list when you delete it, or when it reaches its expiry date (30 days unless you set another, at most 365 days, and daily Backups beyond the number your rule keeps). Its objects in object storage are removed after the same grace period.
• (c) Logs are kept for the period of your Plan (3 days on Free, 30 on Paid) and then deleted. We check every hour and delete Logs in whole pieces, so a line can stay a little longer than the period. You can delete an App’s Logs from before a chosen time at any time: from then on nobody can read them, pieces that hold only older lines are deleted at once, and the other pieces are deleted when they expire. The last 1 MiB of what a deleted instance printed stays on its host for 7 days. Logs of a deleted App stay until their period ends, unless the App went with a closure of the Account or a deletion for unpaid storage: then they become unreadable with the rest when the project’s key is destroyed (Section 12.2(a)).
• (d) Templates built from your images are removed by our hosts once nothing has used them for 7 days.
• (e) Our database backups are encrypted and kept for about 30 days (Annex II, items 3 and 8). Records about your Sandboxes in them include environment variables and other settings, encrypted.

12.3 When your Account is closed. We delete what the Account stores: Apps with their Versions and instances, Sandboxes, Snapshots, Volumes, Backups and templates built from your images. We repeat this every few seconds until nothing remains; anything on a host that is unreachable is deleted when the host returns. When nothing remains, we destroy the encryption keys of the Account’s projects (Section 12.2(a)). Section 12.2 then applies to the remaining copies, which can no longer be read.

12.4 When storage is not paid. If your Account stays in debt for unpaid storage for 30 days after we send the first notice, as set out in the Terms of Service, we delete the same things as in Section 12.3 and destroy the keys of the Account’s projects when that deletion has finished (Section 12.2(a)); Section 12.2 applies to the remaining copies, which can no longer be read. The Account itself goes on, and its projects get new keys when something is stored again. We only delete if our email provider accepted both the first notice and the last reminder.

12.5 What is not deleted. After a closure, the values of your secrets and shared variables, and your SSH keys and webhooks, stay in our database, encrypted and no longer usable, with no end date. After a deletion for debt they stay too, and remain usable, because the Account goes on. The records we keep as a controller (Section 3.2) are covered by our Privacy Policy; they include usage records, with the metadata labels you attached, for 13 months.

12.6 No other copies. We delete Customer Content as Sections 12.2 to 12.5 describe, and the remaining copies last as long as those Sections say. We keep no other copy of Customer Content after deletion, and we use the remaining copies for nothing except restoring the Service after a failure.

12.7 On request, we confirm in writing that the deletion in Section 12.3 has been done.

13. US state privacy laws

Where US State Privacy Laws apply to Customer Personal Data, we act as your service provider, contractor or processor under those laws, and:

• (a) we process Customer Personal Data only to provide the Service, for the purposes in Annex I;
• (b) we do not sell or share it, including for cross-context behavioral advertising, and we do not keep, use or disclose it outside our direct business relationship with you or for any purpose other than those purposes, except as those laws allow;
• (c) we do not combine it with personal data that we receive from others or collect ourselves, except as those laws allow;
• (d) we meet the obligations those laws place on us and give it the level of privacy protection they require;
• (e) we tell you if we decide that we can no longer meet these obligations, and you may then take reasonable and appropriate steps to stop and remedy unauthorized use;
• (f) you may take reasonable and appropriate steps, as Section 11 sets out, to make sure that we use it in a way consistent with your obligations under those laws.

14. Liability

Each party’s liability under this DPA is subject to the limits in Section 22 of the Terms of Service, except where Data Protection Laws or the Standard Contractual Clauses do not allow such limits.

15. How long this DPA lasts, and changes

15.1 This DPA lasts as long as we process Customer Personal Data.

15.2 We may change this DPA when the law requires it, or in ways that do not lower the protection of Customer Personal Data. We tell you at least 14 days before a change takes effect, unless the law requires it sooner.

Annex I — Description of the processing

A. The parties

B. The transfer and the processing

C. Competent supervisory authority: as Section 10.3(e) says, and for transfers from Switzerland, Section 10.5.

Annex II — Technical and organizational measures

These measures describe how the Service is built and run.

1. Isolation between customers

• Each Sandbox and each App instance runs in its own Firecracker microVM, a virtual machine with hardware virtualization (KVM).
• Each Firecracker process is started by Firecracker’s jailer: it has its own root directory containing only that machine’s files, its own user and group shared with no other Sandbox, no capabilities, its own PID namespace, its own control group with a limit on tasks, a limit on open files, and only the devices it needs (/dev/kvm, /dev/net/tun and /dev/urandom). Firecracker’s seccomp filter limits the system calls it can make.
• Shared files (template memory and the image disks under Sandboxes) can be read by a Sandbox’s process but not changed or replaced.

2. Network controls

• Each Sandbox runs in its own network namespace. Rules on the host side stop Sandboxes from reaching the host’s own interfaces and SSH, other Sandboxes, private address ranges and cloud metadata addresses.
• Sandboxes of the same Project can reach each other on the Project’s private network; nobody else can reach those addresses.
• You can set egress rules per Sandbox and per App to allow or deny outbound traffic by host, and by method and path for HTTP. A secret can only be sent to the hosts that an admin allowed when storing it.
• Our log exporter and image puller run in a separate network namespace that can reach only the public internet. Log export endpoints must use HTTPS and public addresses, and redirects are not followed.

3. Encryption at rest

• The data drives of our hosts, which hold Sandboxes’ disks and memory, Volumes and Snapshots, are encrypted with LUKS2 (AES-XTS, a 512-bit key), so a drive that leaves a host holds only ciphertext.
• Copies of Sandbox disks and memory, and Backups, are encrypted with AES-256-GCM on the host before they are sent to object storage. Each object has its own key, derived from a key that belongs to your Project alone, the object’s name and random bytes stored with the object. Our control plane makes a Project’s key when the Project is made and keeps it encrypted in its database; a host is given only the keys of the Projects placed on it, and loses them when nothing of the Project is left there. The object storage provider never has these keys.
• Log pieces are compressed and encrypted with AES-256-GCM before they leave the host, with a key that belongs to your Project alone. The control plane makes that key and keeps it encrypted.
• In our control plane’s database, these values are encrypted with AES-256-GCM, each with its own key derived from a master key, which is kept by an external key-management service and is never stored on our disks (our software decrypts it once, when it starts, and holds it in memory only): your secrets’ values; the saved settings of Sandboxes, Snapshots and Volumes (which include environment variables); App and Version settings and deployments; shared variables; Log export credentials; webhook signing keys; and the keys used to reach our hosts.
• Secrets copied to a host are kept there encrypted with AES-256-GCM, one file per secret.
• Backups of the control plane’s database are compressed and encrypted with age to public keys; the private key is not kept on our servers.

4. Encryption in transit

• Visitors and API clients reach the Service over TLS (TLS 1.2 or later); plain HTTP on port 80 is redirected to HTTPS.
• The control plane and hosts, and hosts at different sites, talk over WireGuard tunnels.
• Connections from our software to Stripe and our email provider use HTTPS[, and so do connections to object storage].
• Webhooks are sent to the address you give; use an https:// address to have them encrypted.
• If you set an egress rule that inserts a secret or filters HTTP requests for a host, our node ends the TLS connection to that host and opens a new TLS connection to it.

5. Access control

• API keys belong to a Project, carry scopes, and are stored only as hashes. Sandbox tokens open only one Sandbox and expire (after one hour unless set otherwise, at most 30 days).
• Console users sign in with a password stored as an Argon2id hash. Sessions use a cookie that scripts cannot read and that is sent only over HTTPS; changes made with a session must come from the console’s own origin with a header that other sites cannot set. Sign-in, sign-up, password reset and invitations are rate limited.
• Roles in an Account (owner, admin, member) limit who can manage billing, members and keys with the admin scope.
• Operator access to our servers uses keys kept in files readable only by their owner. [Access is limited to staff who need it.]

6. Logging and audit

• Every API call that changes something is recorded in the Project’s audit log before the answer is sent: who, what, when, from which address, and the result. Audit records are kept for 90 days in the database[ and then archived encrypted in object storage].
• Secret values never appear in answers, error messages, logs, audit records or events.

7. Data minimization in platform records

• Request lines in Logs leave out headers, bodies, query strings and visitors’ IP addresses.
• When our edge logs a request it could not pass on, it replaces signatures and tokens and leaves out the Cookie, Authorization and Referer headers.

8. Availability and recovery

• [Where replication is on,] hosts copy Sandbox disks to object storage continuously, and memory when a Sandbox sleeps, so that a Sandbox can be continued on another host if its host is lost.
• The control plane’s database is backed up every 15 minutes (the last 96 backups and one for each of the last 30 days are kept), and a standby copy in another Region can take over.

9. Deletion

• Deletions follow Section 12 of this DPA. Deleted objects in object storage are removed by a clean-up process after a grace period of [one day].

10. Payment data

• Card numbers are entered only on pages hosted by Stripe and never reach our servers.

11. Organizational measures

• [Confidentiality agreements for staff and contractors.]
• [Security training.]
• [How we handle and test security incidents.]
• [Vulnerability management and patching.]
• [Physical security, provided by our hosting providers’ data centers.]

12. [Drafting note — not in place today, remove before publishing:

• Hosts’ root disks, which hold the operating system, our software and its system logs, are not encrypted; the data drives that hold Customer Content are (item 3).
• The copy of the control plane’s database that keeps the standby up to date is not encrypted by our software, only by the storage provider. Account, billing and audit data in the database are not encrypted by our software.
• The node’s main daemon runs as root and parses network requests, so a flaw in it would bypass the jail.
• Operator reads of Logs are not yet audited.
• A Sandbox shares the host’s hardware with other customers’ Sandboxes (side channels), and the host kernel and KVM are part of the attack surface.]

Annex III — Sub-processors