Data Processing Agreement

This agreement forms part of the Terms of Service between [BEESWORX LEGAL NAME] (Reg. No. [BEESWORX REGISTRATION NO.]) ("Beesworx", "Operator") and each tenant ("Customer", "Responsible Party") using Forge. It governs Beesworx's processing of personal information on the Customer's behalf, as required by section 21 of the Protection of Personal Information Act 4 of 2013 ("POPIA").

1. Roles

The Customer is the responsible party for personal information it processes using applications, databases, and other resources it deploys on the platform (e.g. its own end users' data in a Postgres database it provisions).
Beesworx is the operator: it processes that personal information only to provide the infrastructure, and only on the Customer's instructions (given by configuring and using the Service).
This agreement does not cover personal information Beesworx collects about the Customer's own account holders as platform users; see the Privacy Policy for that.

2. Scope of processing

Beesworx processes personal information stored within Customer-provisioned resources (PostgreSQL, MariaDB and Redis databases, object storage buckets, application containers and their volumes, backups, application logs, and container images and build caches holding the Customer's application code) solely to: provision, run, monitor, back up, and secure that infrastructure; provide support at the Customer's request; and meet legal obligations.

For the LLM gateway, a passthrough request the Customer's own application sends is not logged or retained beyond what is needed for billing and usage records (model, token counts, cost, status; not the prompt or response body), and is not used for model training by Beesworx.

Separately, where the operator has enabled them, some platform features send Customer content to a third-party AI provider at Beesworx's own initiative rather than the Customer's application's: generating a Dockerfile for a repository deployed without one (when deploying from Git, or when the standard builder is unavailable), diagnosing a failed deploy from its logs, and answering questions in the dashboard AI assistant, which can act on the Customer's resources with the user's own permissions and send the results (for example database query results, environment settings and logs) to the provider. The RAG feature, where enabled for a project, sends uploaded document text to an embedding provider through the LLM gateway. See Schedule 1 for the providers.

3. Security measures (POPIA s19 to s22)

Beesworx implements the following technical and organisational measures, proportionate to the risk, to secure the integrity and confidentiality of personal information processed on the Customer's behalf. The Security Statement describes them in more detail.

POPIA requirement	Control
s19(2): appropriate, reasonable technical and organisational measures	Customer databases are separate PostgreSQL, MariaDB and Redis databases with per-tenant credentials, not a shared table Forge filters by tenant. Forge's own control-plane metadata (org membership, billing state, and similar platform records; not Customer databases) is scoped in application code by organisation, with PostgreSQL row-level security as a secondary check on the read path, active where the platform has configured a dedicated low-privilege database role for it.
s19: prevent unauthorised access	Per-org and per-app network isolation; role-based access control (owner, admin, member, viewer, mapped to a fixed read, deploy or admin permission level); API keys limited to a read, deploy or admin permission no higher than their issuer's; credentials hidden from users below deploy permission; a sandboxed container runtime (gVisor) for every Customer application container. Platform administrators retain direct technical access to Customer databases (query) and containers (exec) as an operational necessity of running the Service. This access is restricted by policy (support requests, security incidents, and legal obligations), not by a technical control on every such path, and not every such access is currently recorded in an audit trail (see below).
s19: prevent loss, damage, unauthorised destruction	Secrets and database credentials encrypted at rest (AES-256-GCM under a server-held key); where scheduled backups are enabled, a daily encrypted backup of each PostgreSQL database, each dedicated Redis instance and each managed MariaDB database, optionally copied to a separate storage location (object storage and non-dedicated Redis are not covered by this backup); a documented restore procedure
s19: network and egress controls	A network egress boundary, enabled by default, blocking traffic that leaves the host from every tenant container to cloud metadata endpoints and private or internal network ranges, closing a common SSRF and data-exfiltration path; where configured, an outbound port block against direct-to-mail-server and known mining-pool ports
s19: identify and respond to risks	Where enabled, automated detection and stopping of sustained CPU abuse (a mining signature); audit logging of administrative and lifecycle actions (not yet universal: database query, Redis command and container exec access and some resource-management actions are not currently audited); the egress boundary is re-applied every 30 seconds so a configuration gap self-heals
s20: operator processes only on instruction	Beesworx acts through the Service's documented surfaces (dashboard, REST API, CLI, MCP server) as configured by the Customer, subject to the direct platform-administrator access described above
s21: written contract with operator	This agreement, incorporated into the Terms of Service
Sub-operators	Listed with the basis for use in Schedule 1; Beesworx remains responsible for each sub-operator's compliance with the same security standard

Known limitations (disclosed, not concealed):

The egress boundary protects traffic leaving the host. A container reaching an address the host itself owns (such as its Docker bridge gateway), or a container on another Docker bridge network on the same host, is out of its scope.
The automated controls above marked "where enabled" or "where configured" are set per platform installation, not per plan tier [OWNER TO LIST WHICH ARE ACTIVE ON FORGESERVER.APP: SCHEDULED BACKUPS, OFF-HOST BACKUP COPY, OUTBOUND PORT BLOCK, MINING DETECTION, AI FEATURES]. The gVisor sandbox for Customer workloads has been enabled on forgeserver.app since 30 September 2026.
Platform administrators have standing, direct read access to Customer databases and the ability to execute commands in Customer containers. This is not gated behind a per-request Customer approval, and query and exec access is not currently written to the audit log. Treat this as you would any managed-infrastructure provider's operational access.

4. Breach notification

If Beesworx becomes aware of a security compromise that has led, or may lead, to unauthorised access to or acquisition of personal information processed on the Customer's behalf, Beesworx will notify the Customer's org owners and admins without undue delay and in any event within [BREACH NOTIFICATION WINDOW, e.g. 72 hours] of becoming aware, providing the information reasonably available at that time (nature of the breach, categories and approximate number of records affected, likely consequences, and measures taken or proposed). The Customer remains responsible for any onward notification to the Information Regulator and affected data subjects required under POPIA section 22, but Beesworx will reasonably assist with that notification.

5. Sub-operators and cross-border transfers

See Schedule 1 for the current list of sub-operators, what each processes, and the POPIA section 72 basis for any transfer outside South Africa. Beesworx will not appoint a new sub-operator with access to Customer personal information without [PRIOR NOTICE PERIOD, e.g. 30 days' notice, with a right to object] to the Customer, except where operationally necessary sub-operators (e.g. the hosting data centre) are already disclosed at signature.

6. Assistance and audits

Beesworx will provide reasonable assistance to the Customer in responding to data subject requests and Information Regulator enquiries relating to personal information processed under this agreement, and will make available the information reasonably necessary to demonstrate compliance with this section. [AUDIT RIGHTS AND FREQUENCY, ATTORNEY TO ADVISE, given the multi-tenant nature of the platform: a physical or on-site audit of a shared platform is typically replaced by a security summary or report].

7. Deletion and return on exit

On termination of the Customer's account (whether by the Customer or following the suspension ladder in the Acceptable Use Policy), Beesworx will, at the Customer's election made before or at termination:

Return: an owner or admin can self-serve an export archive containing a dump of each PostgreSQL and managed MariaDB database, secrets, the org's audit log, its member list, and app and resource metadata. The export does not include object-storage contents (bucket metadata only; download the objects themselves with the bucket's own S3 credentials before termination), Redis data, container volumes, or container images; these can be requested from Beesworx separately. Export is not available while the org is suspended: request it, or request a temporary reactivation to self-serve it, before that point.
Delete: as part of org deletion, Beesworx tears down provisioned databases, object storage buckets, backups and their off-host copies, the Customer's running containers and their volumes (which takes their local container logs with them), the container images built from the Customer's application code (and their rollback tags), the images the Customer pushed to the platform's built-in container registry under their org's ID namespace (every tagged image, including each platform variant of a multi-platform image, is deleted and can no longer be pulled), and secrets. The registry's underlying storage is reclaimed by an operator maintenance step (garbage collection) rather than at the moment of deletion. Until that step, an earlier version of a tag the Customer overwrote remains in storage and is retrievable only by its exact content digest (a 64-character hash the registry does not list); nothing remains retrievable by name. [ENG/ATTORNEY: commit to a maintenance interval.]

Absent an election, Beesworx will delete Customer personal information following the process in the Acceptable Use Policy's suspension ladder, which is not automatic by default.

Audit log: retained by design, minimised on delete. The structured audit trail (what was done, when, to which resource, by which account identifier: action, target type and ID, actor identity ID, timestamp) is Beesworx's own accountability and security record and is retained after org deletion (the organisation reference is cleared, the row is kept). On deletion, the free-form columns of each of the org's audit entries (the detail field, which can contain connection strings or other personal information, and the target name, which can be an invitee's or member's e-mail address) are scrubbed, so what survives is the minimised trail, not the Customer's operational data or its people's contact details. If the scrub cannot complete, the deletion stops and is retried rather than completing with the data in place. [ATTORNEY: confirm this retention-with-minimisation basis and set a retention period for the structured trail.]

Known gaps: data that is not currently guaranteed to be deleted with the org, disclosed rather than promised away:

Slug-named registry repositories (organisations created before slug reservation). Images pushed under the org's short name (slug) are not removed automatically for an organisation created before slug reservation was introduced, because the same name may belong to the operator; they are removed on request. For organisations whose slug was reserved at creation, the slug namespace is purged with the org. Images under the org's ID namespace are always removed.
Shared build cache. Layers from the Customer's builds may persist in the platform's build cache after deletion. The cache is shared by every customer and does not record which customer a layer came from, so it cannot be purged for one customer alone; layers age out as the cache is trimmed or pruned. [ENG: per-customer build caches are the fix.]
Centrally collected logs. Where the operator runs log collection (a metrics and log stack), the Customer's application logs shipped there are retained for the configured window (see the Privacy Policy) independent of org deletion, and are not purged early by a delete. (The containers' own local logs are deleted with the containers.)

Beesworx will treat a report of any of the above as a priority fix rather than a documented limitation to live with indefinitely.

8. Liability

[ALLOCATION OF LIABILITY BETWEEN RESPONSIBLE PARTY AND OPERATOR FOR A POPIA BREACH, ATTORNEY TO ADVISE, typically each party liable for breaches caused by its own conduct or instructions].

Schedule 1: Sub-operators and cross-border transfers

This list supports the POPIA Operator Agreement. It names every third party that may process personal information on Beesworx's behalf as part of operating Forge, what they process, and, where the party is located outside South Africa, the POPIA section 72 basis relied on for the transfer.

POPIA section 72 permits a cross-border transfer where, broadly: the recipient is subject to a law, binding corporate rules, or agreement that provides an adequate level of protection substantially similar to POPIA's conditions (s72(1)(a)); or the data subject has consented (s72(1)(b)); or the transfer is necessary for contract performance (s72(1)(c) and (d)). [ATTORNEY TO CONFIRM THE PRECISE BASIS PER SUB-OPERATOR BELOW; this table records our working assumption only.]

Sub-operator	What it processes	Location	Used for	POPIA s72 basis (working assumption)
Hosting data centre	All infrastructure: compute, databases, storage, network. This is the physical location of all Customer data	[HOSTING DATA CENTRE NAME AND LOCATION FOR FORGESERVER.APP]	Hosting the platform	If in South Africa: no cross-border issue. If outside: standard contractual clauses or an adequacy assessment. [ATTORNEY TO CONFIRM]
RevEx (Beesworx's own billing product)	For each org: its ID, name, and the e-mail address of the user who sets up billing; subscription and plan choices; a monthly usage summary per meter (quantity, unit and amount). RevEx returns plans, invoices, subscription status and whether a payment method is on file. Card and bank details are captured by RevEx's hosted checkout and its payment rail, never by Forge	[REVEX HOSTING LOCATION]; payment rail [PAYMENT RAIL PROVIDER AND LOCATION]	Subscriptions, invoicing, usage billing and payment collection	s72(1)(c): necessary to bill for the Service. [ATTORNEY TO CONFIRM whether an internal Beesworx product is a separate sub-operator or part of Beesworx's own processing]
Buzzz (Beesworx's own e-mail product), beta request form	The website's "Request beta access" form (buzzzmail.co.za/f/forge-beta) collects the visitor's e-mail address, first and last name, company, and a free-text description of what they want to run; Buzzz stores it as a contact and e-mails the request to Beesworx	[BUZZZ HOSTING LOCATION]	Handling beta access requests	s72(1)(b) or (c): the visitor submits the form to request access. [ATTORNEY TO CONFIRM; the form currently shows no privacy or consent text]
Buzzz, platform mail relay, delivering through Amazon SES	Where the operator has enabled the platform relay, application e-mail for an org that has not configured its own provider and has verified a sender domain: recipient address, sender, subject, HTML and text body, reply-to, plus that org's identity e-mail (verification codes and password-reset links to the tenant's own end users). Buzzz also holds each such org's verified sender domains and tags each message with the org's ID. An app sends through it only if its configuration binds the platform's managed e-mail	[BUZZZ HOSTING LOCATION]; Amazon SES [SES REGION]	Sending application and identity e-mail, where enabled [OWNER TO CONFIRM ENABLED ON FORGESERVER.APP]	s72(1)(a) and (c). [ATTORNEY TO CONFIRM whether this needs treatment as a separate sub-operator or as part of Beesworx's own processing]
Resend	Platform e-mail not covered by the Buzzz relay: org invites, operator alerts, billing and dunning notices, sign-in verification codes for Forge accounts, and application e-mail for the default org	United States	Sending platform and identity e-mail	s72(1)(a) and (c): Resend's standard data processing terms and contract necessity. [ATTORNEY TO CONFIRM Resend's SCC and adequacy posture]
AI provider for platform features	Where enabled: repository files (to generate a Dockerfile for a repository deployed without one), deploy logs (to diagnose a failed deploy), and dashboard AI assistant conversations, including the results of actions the assistant takes on the user's behalf (for example database query results, environment settings and logs)	[GENAI PROVIDER AND REGION, e.g. OpenAI or OpenRouter, OR "NOT ENABLED"]	Build help, deploy diagnosis and the dashboard assistant	s72(1)(c): necessary to provide the features the Customer uses. [ATTORNEY TO CONFIRM; Beesworx, not the tenant's application, initiates these calls]
LLM providers registered on the platform	Prompts and content the Customer's own application sends through the LLM gateway; and, only if the RAG feature is enabled for a project, the text of documents uploaded to it, for embedding	[LLM PROVIDERS REGISTERED ON FORGESERVER.APP, WITH REGION PER PROVIDER]	LLM inference and embeddings	s72(1)(b) and (c): the Customer's application makes the call and the Customer configures the binding. [ATTORNEY TO CONFIRM]
DNS providers (GoDaddy or Cloudflare, for the platform's own zone)	Domain names and DNS records for the platform's own zone; no personal information beyond what is inherent in a hostname. The platform does not write records for your custom domain; it only reads the TXT record you publish to prove control	[DNS PROVIDER FOR FORGESERVER.APP AND LOCATION]	Certificate issuance and DNS for the platform's own hostnames	s72(1)(c): necessary to operate the requested hostname; no sensitive personal information involved
Public certificate authorities (Let's Encrypt, or another ACME CA used by the web server)	Every hostname on the platform, including verified custom domains, to obtain a TLS certificate; certificates (hostnames only, not content) become visible in public Certificate Transparency logs	Global CA infrastructure	TLS certificate issuance	s72(1)(c): necessary to serve your site over HTTPS; hostnames only
Cloudflare Turnstile or hCaptcha	The signup form's captcha widget, and the visitor's IP address (sent when verifying the token), only when signup captcha is enabled	Provider-dependent	Anti-bot check on signup	Legitimate interest in fraud and abuse prevention. [ATTORNEY TO CONFIRM]
Google Fonts	Every visitor's IP address and browser user agent, on every load of the website, dashboard and signup pages	United States	Web font delivery	s72(1)(a): Google's standard terms. [ENG: self-hosting the fonts would remove this row]
PagerDuty	Alert payloads, only when on-call alerting is configured: app and container names, org IDs and error text, for mining, egress, cluster and backup events	United States	Operational incident alerting for Beesworx staff	Legitimate interest: Beesworx's own operational tooling; contains identifiers and technical details, not Customer database content
Off-host backup storage	An encrypted copy of database backups, only where an off-host destination is configured	[OFF-HOST BACKUP PROVIDER AND LOCATION]	Disaster-recovery copy of scheduled backups	Same basis as the hosting row
Standby cluster nodes	A full replica of the platform's data plane (databases, object storage, container registry), only where multi-node standby replication is enabled	[STANDBY NODE HOSTING AND LOCATION, PER NODE, OR "NOT ENABLED"]	High-availability failover	Same basis as the hosting row
GitHub, GitLab, Bitbucket, or another git host you connect	Your repository contents and webhook payloads and, for pull-request preview comments, the host's API called with your own token, only if you connect a repository	Provider-dependent (GitHub: United States)	Cloning and building your application code	s72(1)(c): at your own instruction; it is your own account and repository, not one Beesworx provisions
Public search engines behind the platform search service	Search queries your application sends through the platform's self-hosted search feature, only where it is enabled	Provider-dependent	Fulfilling search queries	s72(1)(c): at your application's own instruction

Notes

Per-org bring-your-own providers (LLM providers or an e-mail provider key) chosen by a tenant itself are the tenant's own sub-processors, not Beesworx's: the tenant is the responsible party contracting with them directly.
This list will be updated whenever a new sub-operator is added; the Operator Agreement commits to prior notice before a new one gains access to Customer personal information.
Rows marked "only when" or "where enabled" describe conditional processing tied to a platform setting or a feature you opt into; they do not apply to every tenant.