Account access
We use account, Google, Apple, Telegram, and wallet sign-in data to authenticate you, keep your session active, and make sure only you can access your private jobs and outputs.
Privacy Policy
How RenderBoost handles your account, project files, and render data
This policy is intentionally plain-language. RenderBoost is a Blender render-job intake and delivery service, so the main data we handle is account identity, uploaded project files, render job metadata, and final output artifacts.
Last updated: July 11, 2026
Information we collect
Account information: when you create or access an account, we collect the email address, display name we derive or receive from your authentication provider, password authentication data when you use email/password login, session data, and basic account status.
Google sign-in information: if you use Continue with Google, Google provides basic profile information such as your email address, email verification status, name, and profile image. We use this only to create or sign in to your RenderBoost account.
Telegram sign-in and linking information: if you use Continue with Telegram or link Telegram from your account page, Telegram may provide your Telegram user ID, username, and name. We do not request, store, or use your Telegram profile image.
Wallet sign-in information: if you use Continue with Wallet, we store the wallet address you signed with, the chain ID used for the sign-in request, and standard session data needed to authenticate that account. We do not request on-chain transaction history or spend permissions.
Render-job information: we store the project filename, file size, upload metadata, selected render backend, frame range, job status, progress events, error messages, and final output metadata.
Project files and outputs: uploaded .blend or .zip project files, rendered frames, previews when available, and final downloadable artifacts are stored so the render job can be processed and delivered.
Technical information: we may store server logs, request metadata, worker events, delivery logs, and security or abuse-prevention records needed to operate the service reliably.
Aggregate site usage: we count page views in UTC daily and hourly buckets by normalized page path, a two-letter country code, and an aggregate heuristic traffic class (`human`, `bot`, or `unknown`; older or unclassified totals are reported as `legacy`). We may inspect an IP address, user agent, and other request metadata transiently to derive the country and traffic class, then discard that metadata. The counters retain only aggregate bucket dimensions and counts: normalized path, country, class and classifier version, traffic source, browser family for human-classified views, bot provider and purpose, verification level, and classification reason. Provider and purpose labels are heuristic; `user_agent_only` means the bot identity was not independently verified against provider network ranges. The counters store no raw or hashed IP address, user agent, referrer, fingerprint, visitor or session identifier, or individual page-view event. `human` is a heuristic page-view class, not proof of a person. These counters cannot identify unique visitors or reconstruct a person's browsing history.
Anonymous live-presence status: while a visible browser tab is open, it may refresh one shared activity timestamp. We retain that timestamp only for a short rolling window to tell whether the site has any active visitor. It contains no account, visitor, device, page, IP address, or event history.
Cookies and browser storage
RenderBoost uses first-party cookies and temporary browser storage only for account sessions, sign-in security, interface language, and completing actions you request. We do not use advertising cookies or analytics cookies. Referral links carry a signed, expiring claim in the link itself instead of storing referral attribution in a browser cookie. The aggregate page counters described above do not assign or read a visitor ID.
How we use information
Render processing
We use uploaded project files and render settings to queue, render, retry, troubleshoot, package, and deliver your requested Blender outputs.
Service operation
We use logs and job events to detect failures, protect the service, diagnose bugs, prevent duplicate work, and improve reliability.
Storage and service providers
RenderBoost uses third-party infrastructure providers to run the service. This can include Postgres for relational data storage, Backblaze B2 for project and output object storage, email providers such as Resend or Mailgun for account emails, Google and Telegram for social sign-in, browser wallet providers for local wallet signature prompts, and rendering infrastructure providers for job processing. These providers process data only as needed for the service to work.
Project privacy
Uploaded project files and render outputs are not published publicly by default. They are associated with the account that submitted the job. We may access files or logs when needed to debug a job, operate the renderer, investigate abuse, or respond to a support request.
Data retention
We keep account records while your account exists. Project uploads, generated frames, and final outputs may be deleted after a retention period or when they are no longer needed for delivery, debugging, abuse prevention, or legal compliance. Some operational logs may be kept separately for reliability and security.
Your choices
You can choose not to use Google, Apple, Telegram, or wallet sign-in and instead use another available sign-in method. You can also contact us to request account deletion or to ask questions about your data. Some records may need to be retained when required for security, abuse prevention, dispute handling, or legal obligations.
Contact
For privacy questions, account requests, or support, contact the support address shown on the RenderBoost Google sign-in consent screen or use the support channel provided on the site.