Privacy

• Scenes and renders are private. There is no gallery to opt out of.
• Nothing you upload or render is used to train any model, ever.
• No cookies for tracking, no advertising trackers and no cookie banner on the site. Page views are counted anonymously. The SDK sets no cookies and sends nothing except the scene you asked it to render.
• Encrypted in transit and at rest. Result URLs are signed and expire. API keys are stored only as hashes.
• Storage is tenant-isolated: assets are addressed per project.
• Results are deleted after a short retention window, 30 days by default, which you set per project. Any render, and the whole account, can be deleted at once by you.

1a. Account

• Email address and a password hash. The password itself is never stored.
• An optional display name, when the account was created, and the plan, balance, budget and concurrency settings on it.

1b. Billing

Payments are processed by Paddle, which acts as our Merchant of Record. Paddle collects your payment method, card details and billing address directly, and works out and remits VAT. We receive and keep only: your Paddle customer ID, transaction IDs (so a repeated payment notification cannot credit you twice), subscription ID, plan name and status, and the amounts credited. We never see or store card numbers.

1c. Projects, keys and tokens

• Project names, allowed origins, a webhook URL and its signing secret, the retention window and a monthly budget.
• API keys and browser tokens are stored only as SHA-256 hashes with a short prefix. A database dump is not a set of live credentials, and a lost key can only be replaced, never recovered.
• A browser token also records how many renders and how much it has spent, and any subject you attached when you minted it.

1d. Scenes and renders

The SDK exports your three.js scene as a manifest plus content-addressed assets. Where each part goes:

• Assets (geometry, textures, HDRIs, IES profiles and animation data) go from the browser straight to object storage under your project’s own prefix. The control plane sees their hashes, sizes and types, not their bytes.
• The manifest (camera, lights, material parameters, node-graph IR, color settings, the compatibility report, renderer versions and any productState you attach) is stored with the render record.
• Results (the rendered image, clip or lightmap, and the progressive preview) are stored in object storage and served on signed, expiring URLs.

The SDK sends no source code, no GLSL, no DOM and nothing at all from check(), which runs entirely in the browser. See Concepts for what a manifest contains.

1e. Operational records

• Every state transition of a render, timestamped.
• The error a failed render returned: its code, message, reason and fix.
• GPU seconds, cost and whether the cache was hit, per render. This is the ledger your usage page and invoices are read from.
• Webhook deliveries: the payload sent to your endpoint and the response it gave.
• The Origin header of API requests, checked against a token’s allowed origins.
• Our hosting providers keep short-lived request logs that include IP addresses.

1f. The site itself

bakery3.com counts page views with Cloudflare Web Analytics. For each page view it records the page, the site that linked to it, the browser and device type and the country. It sets no cookie, stores nothing in your browser and uses no identifier, so a visit cannot be tied to a person or followed across sites. There are no other analytics or marketing scripts. When you sign in, two things are kept in your browser’s localStorage: the session tokens that keep you signed in, and a hint (your id, name and email) so the static pages can show that you are. Both are removed when you sign out. Paddle’s checkout script loads on the billing page only, and what it does there is governed by Paddle’s own policy.

The sign-in page loads Cloudflare Turnstile, which checks that a person and not a script is signing in or creating an account. It reads your IP address and signals from your browser, sets no advertising cookie, and gives us a one-time token that we send back to Cloudflare to confirm. We keep neither the token nor the result. What Cloudflare does with those signals is covered by the Turnstile privacy addendum.

When your application renders on behalf of its own visitors, their browser sends the scene to us under your project, using a browser token you minted. We set no cookies, run no analytics and fingerprint nothing in their browser. We do not know who they are unless you put an identifier in the token’s subject or the manifest’s productState.

For that data you are the controller and we process it on your instructions. The sub-processors and retention below apply to it, and deleting the render, the project or the account deletes it. Their IP address reaches our hosting providers’ request logs like any other request. See Auth for how browser tokens are scoped.

• To render what you asked for and return it to you.
• To charge the estimate, cap it at the maximum you accepted, and show you what it actually cost.
• To keep an account from spending past its balance, plan credit or budget, and to refuse a browser token used from an origin it was not minted for.
• To prevent abuse of the signup credit and of GPU time.
• To answer support requests, which usually means reading a render’s manifest and error together with you.
• To improve the translator and the cost estimator, from compatibility reports, failure records and measured render times. Never from your assets.

We do not sell your data, and we do not use your scenes or renders to train any model.

• Contract: your account, rendering, billing and support.
• Legitimate interest: security, abuse prevention, debugging, reliability, and counting page views to see how people find the site.
• Legal obligation: keeping accounting records.
• Consent: not currently relied on, because nothing optional is tracked. If that changes, the site will ask before it loads anything, and this page will say so.

Data is shared only with the providers below, and only to operate the service.

Workers hold no storage credentials. Each is handed a signed URL per object, scoped to that object alone and expiring within the hour. A worker keeps a cache of the assets it has fetched and the frames it has traced, so a repeat render costs nothing; entries unused for 30 days are removed from it.

• Results and previews: deleted when the project’s retention window ends. 30 days by default; you can set anything from 1 to 365 days per project. An hourly sweep deletes the object from storage before it touches the row. To delete sooner, the Delete button in the dashboard or DELETE /v1/renders/:id removes the objects at once.
• Uploaded assets: kept under your project’s prefix so a later render of the same scene uploads only what changed. An asset no render has used for longer than the project’s retention window (never less than two days) is deleted.
• Worker caches: the assets and traced frames a render worker keeps on its own disk are removed after 30 days unused.
• Render records: the manifest, timestamps, cost, GPU seconds and renderer versions outlive the images, so your usage history and invoices stay auditable. Geometry, textures and pixels are not in them. Deleted with the account.
• Browser tokens: removed an hour after they expire.
• Account: kept while it is active. You delete it yourself from Settings. Keys, tokens and sessions stop working in the same instant; every asset, render and record is purged in the background, normally within minutes. Any remaining balance is forfeited and a plan is cancelled at once.
• Billing records: what Norwegian accounting law (bokføringsloven) requires, currently five years, in the form it requires and nothing more.
• Request logs: retained briefly by our hosting providers for security and debugging.

See Limits for the retention setting and Uploads for how assets are addressed.

Under the GDPR and the Norwegian Personal Data Act you have the right to:

• Access the personal data we hold about you.
• Rectify inaccurate or incomplete data.
• Erase your data.
• Port your data to another service.
• Restrict or object to processing.

Most of this you can do yourself. The dashboard shows and edits your account and projects, keys can be revoked at any time, the API lists your renders and returns each result in the format you asked for, and Settings deletes any render or the whole account. For everything else, write to hello@bakery3.com. You also have the right to lodge a complaint with the Norwegian Data Protection Authority (Datatilsynet).

Convex, Cloudflare, Runpod and Paddle may process data outside the European Economic Area, in the United States in particular. Where they do, we rely on Standard Contractual Clauses or an adequacy decision such as the EU–US Data Privacy Framework where the provider is certified under it. If your work has to stay inside a region, write to hello@bakery3.com before you rely on it.

Bakery3 is not intended for anyone under 18 and we do not knowingly collect personal data from children. If you believe a minor has given us data, contact us and we will delete it promptly.

We may update this policy as the service changes. The effective date at the top says when it last did. A change that widens what we collect or who we share it with will be announced to account holders by email before it takes effect.

For any privacy question, write to hello@bakery3.com. Read the Terms for the rest of the agreement.