Privacy Policy

1. Controller and contact

The controller responsible for the processing of personal data described in this Privacy Policy is the operator of this Archive Deployer instance.

2. Scope of this policy

This Privacy Policy applies to the hosted Archive Deployer web application at https://push.leunos.com (the “Service”), which runs on the hosting platform configured by its operator: Vercel or another compatible Node host, or OpenAI ChatGPT Sites using Cloudflare Workers.

The Service lets you unpack an archive, folder, or individual files in your browser and create a Git commit with selected files in a GitHub repository, using GitHub OAuth or a GitHub Personal Access Token for authentication.

3. Hosting and server-side request processing

The Service runs on the hosting platform configured by its operator: Vercel or another compatible Node host, or OpenAI ChatGPT Sites using Cloudflare Workers. Delivering any web application involves ordinary server and network processing of technical request data. When you use the Service, the hosting platform and the application therefore process data such as:

• your IP address (as required to deliver responses and for network security),
• request metadata such as the requested URL, response status, and request time,
• timestamps, and
• the user agent and similar technical information transmitted by your browser.

Such data appears in standard hosting and network logs maintained at the infrastructure level. The application’s own application-level logging is deliberately minimized (see section 10), but this does not mean the hosting platform receives no personal data: ordinary web request processing on the platform inherently involves the technical data listed above.

4. Website analytics (Vercel Web Analytics)

The Service integrates Vercel Web Analytics on its Vercel deployments to measure aggregated website usage statistics. Vercel has designed this product to operate without analytics cookies or persistent device identifiers: no analytics cookies are set in your browser. According to Vercel’s documentation, information such as the following may be processed:

• the pages you visited (page paths without query parameters),
• the referrer that led you to the Service (subject to your browser’s referrer policy),
• approximate location derived from the incoming request (country level),
• browser, operating system, and device category (mobile, tablet, or desktop).

Visitors are distinguished without cookies using a hash derived from the incoming request, which Vercel states is automatically discarded after about 24 hours and is not used to track you across different websites or applications. The data is used for aggregated, anonymous statistics only and is not used for advertising, profiling across websites, or marketing tracking.

Because no information is stored on or read from your device for this purpose, no cookie consent is requested for analytics.

5. Cookies and browser storage

The application sets only strictly necessary cookies. No advertising, preference, or analytics cookies are set by the Service.

Because only technically essential cookies and no other device storage are used, the Service does not display a cookie consent banner.

6. GitHub authentication

You can authenticate with GitHub OAuth or with a GitHub Personal Access Token (PAT). For OAuth, the application uses state, PKCE, and redirect binding and requests the repo, read:user, and workflow scopes. From GitHub, the application receives the account information required for the Service: your GitHub user ID, login, avatar URL, and, if applicable, your display name.

For PAT sign-in, you provide a personal access token, which the application validates against GitHub. GitHub credentials (OAuth tokens and PATs) are processed to perform the authenticated GitHub operations you request. Before any persistent session storage, GitHub tokens are encrypted with AES-256-GCM using a server-side key; they are not stored in plaintext and not exposed to your browser in a readable form.

You can revoke access at any time — for OAuth via GitHub’s authorized OAuth Apps settings or by disconnecting in the application, and for PATs by deleting the token in your GitHub settings. Signing out deletes the session cookie and, where applicable, the server-side session record immediately.

7. GitHub API integration

To provide deployments, the application communicates with the GitHub API using your credentials. At your direction, information required to perform a deployment may be transmitted to GitHub, including:

• the repositories you select (or the parameters for a new repository),
• branch names, including the optional creation of a new branch,
• file paths and the contents of the files you selected for deployment,
• the commit message and target path, and
• an optional pull request title and body.

The application lists only repositories and branches for which your credential has the required write permissions. GitHub processes this data as a controller in its own right under its own privacy statement.

8. Archive and file processing

Original archives are unpacked in your browser. Files you did not select never leave your browser. Only the contents of the files you select are sent onward for deployment. The archive safety policy applies limits and skips unsafe or unsupported entries, for example:

• a total source size of 500 MiB and up to 1,000 extracted files,
• a per-file limit of 5 MiB, or 3 MiB when a file is sent straight through the API without intermediate object storage, and
• rejection or skipping of unsafe paths (such as path traversal patterns), sensitive defaults (.env files), system directories (.git, node_modules), and oversized entries. Skipped entries are reported to you.

9. Temporary object storage and retention

• Successful deployment: temporarily stored file contents are deleted immediately after the deployment is durably confirmed in GitHub.
• Failed or retryable runs: stored contents are retained for up to 72 hours after the latest terminal failure so an authorized restart can reuse them; afterwards they expire permanently.
• Abandoned uploads: staging sessions that were never submitted for deployment expire after approximately 24 hours.
• Deployment and run records: records that support retries, restarts, and idempotency — including an encrypted copy of the GitHub credential needed to finish or reconcile a run — are kept for up to 7 days.
• Cleanup metadata: upload metadata in Redis or D1 can outlive staging expiry by up to 7 days so the daily cleanup job can discover and delete stranded objects.

Temporary object storage is strictly working space. Do not use it as a backup or permanent storage location.

10. Durable state processing (when configured)

When this deployment has Redis or Cloudflare D1 configured, the application stores the following data in that state store under a project-specific key prefix, each with its own expiry:

• server-side session records for opaque session identifiers, including the encrypted GitHub token,
• short-lived OAuth state records (the encrypted PKCE verifier and redirect binding),
• upload and deployment metadata: file paths, file sizes, hashed identifiers, manifest state, ownership (which account owns which upload or run), and deployment intent hashes used for idempotency,
• rate-limit windows, and
• related operational state such as cleanup leases and health markers.

File contents are not stored in Redis or D1. File contents are held only in temporary object storage (section 8) or pass through memory on their way to GitHub without being persisted.

11. Logging, rate limiting, and security

The application’s own operational logs are deliberately minimized. Log entries contain metadata such as timestamps, request IDs, operation names, outcomes, file and byte counts, durations, execution mode, stable error codes, and hashed identifiers (truncated, SHA-256-derived values for user and upload identifiers). Tokens, file contents, signed URLs, and similar secrets are intentionally kept out of these logs. Rate limiting for unauthenticated authentication endpoints uses keys derived from your IP address; rate limiting for authenticated operations uses your session user identifier. Rate-limit entries expire with their time window. Beyond this, infrastructure providers may maintain their own platform logs (see section 3).

Security measures include TLS encryption in transit, HTTP-only cookies, AES-256-GCM encryption of GitHub tokens and (without a durable state store) of the session cookie, OAuth state and PKCE, same-origin checks against CSRF, non-force Git ref updates, and least-privilege handling of your credentials.

12. Purposes and legal bases

• Provision of the requested service — authentication, session management, repository and branch selection, and transmission of selected files to GitHub: Art. 6(1)(b) GDPR (performance of the service you request). The session and OAuth state cookies are technically essential for this and exempt from consent under § 25(2) No. 2 TDDDG.
• Security, abuse prevention, and reliable operation — rate limiting, CSRF protection, operational logging, error handling, and cleanup of temporary data: Art. 6(1)(f) GDPR (legitimate interest in the secure and reliable operation of the Service).
• Aggregated usage statistics — Vercel Web Analytics as described in section 4: Art. 6(1)(f) GDPR (legitimate interest in understanding and improving usage of the Service at an aggregate level). No analytics cookies are set, and the data is not used for advertising or cross-site tracking.

13. Recipients of personal data

Personal data is shared only with the providers necessary to operate the Service:

• Vercel, Inc. — web application hosting where selected, Vercel Web Analytics on Vercel deployments, and (where used for temporary file storage) private Vercel Blob object storage.
• OpenAI and Cloudflare — on ChatGPT Sites deployments, hosting through Cloudflare Workers, D1 for durable state, and R2 for temporary file storage.
• GitHub, Inc. — the GitHub API operations you direct (section 7).
• Object storage provider — for temporary file storage, whichever private storage provider is configured for this instance (for example AWS S3 or an S3-compatible service such as Cloudflare R2, MinIO, or Backblaze).
• Redis provider — where configured (for example Upstash or a self-managed Redis/Valkey service operated by the operator).

Providers acting on the operator’s behalf are bound by data processing agreements. The application contains no third-party advertising or tracking scripts.

14. International data transfers

The Service uses its operator’s selected hosting infrastructure, and the providers listed in section 13 may process personal data in countries outside the European Economic Area, in particular the United States. Where personal data is transferred to countries without an EU adequacy decision, the operator relies on the European Commission’s adequacy mechanisms where applicable (such as the EU-US Data Privacy Framework) or on the EU Standard Contractual Clauses concluded with the respective provider, together with additional technical measures. Please refer to each provider’s privacy documentation for the details of their transfer safeguards.

15. Retention periods

• Session cookies and server-side sessions: 7 days of inactivity, at most 30 days; deleted immediately on sign-out.
• OAuth state cookie and records: 10 minutes, or until sign-in completes.
• Temporarily stored file contents: deleted on commit confirmation, or up to 72 hours after the latest terminal failure; abandoned uploads expire after approximately 24 hours.
• Deployment, run, and credential records in Redis or D1: up to 7 days; upload cleanup metadata up to 7 days beyond staging expiry.
• Application audit log entries: for the period the hosting provider retains application logs; entries contain no plaintext secrets (section 11).
• Infrastructure-level hosting and analytics data: according to the retention terms of the respective provider.

16. Your rights

Under the GDPR you have the right to access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction of processing (Art. 18), data portability (Art. 20), and the right to object to processing based on legitimate interests (Art. 21). Where processing is based on consent, you can withdraw that consent at any time with effect for the future.

To exercise your rights, contact the controller listed in section 1. Requests that concern your GitHub account or repositories can often be exercised most directly through GitHub itself, and you can revoke the application’s GitHub access at any time (section 6).

You have the right to lodge a complaint with a competent supervisory authority, in particular in the EU member state of your habitual residence, place of work, or the place of the alleged infringement.

17. Necessity of the processing

The session cookie, GitHub credentials, and the technical request processing described above are necessary to provide the Service you request: without them the application cannot authenticate you or create commits in your repositories, and there is no alternative way to use the deployment feature. Provision of the data is voluntary in the sense that you choose whether to use the Service, but it is technically required for that use.

The Service does not carry out decisions based solely on automated processing that produce legal effects concerning you, and it does not use your data for advertising or profiling.

18. Changes to this policy

This Privacy Policy may be updated to reflect changes in the Service or its providers. The “Last updated” date at the top of this page changes whenever the content changes. The current version is always available at https://push.leunos.com/privacy.