GitStache Privacy Policy

Status notice. This policy was drafted from GitStache's internal architecture, security, and governance records and describes how the product actually works today. It has not yet been reviewed by qualified privacy counsel. See § 15 for the counsel-review status and the on-page caveat we recommend carrying until that review completes.

1. Who we are and what this policy covers

GitStache is a git forge (a source-code hosting, code-review, and continuous-integration platform, an alternative to services like GitHub) operated as a product of Idiom Studios ("Idiom Studios", "we", "us", "our"). The service is available as a hosted offering at gitstache.dev and as software you can run yourself ("self-hosted").

This policy explains what personal data GitStache processes, why, who we share it with, how long we keep it, and the rights you have. It applies to:

• The hosted service at gitstache.dev (the "hosted service" or "SaaS"), where Idiom Studios operates the infrastructure and acts as a data processor for content you upload and, for your own account data, as a data controller.
• Marketing and informational pages on gitstache.dev.

Where this policy does not apply. If you run self-hosted GitStache on your own infrastructure, you (or your organization) are the operator of that instance and the controller of the data on it. Idiom Studios does not process the personal data on a self-hosted instance except in the narrow, non-content cases described in § 4.7 (self-hosted license validation, which is designed to work fully offline). This policy governs the hosted service; a self-hosted operator is responsible for its own privacy notice to its own users.

Controller vs processor, plainly. For the personal data you upload into your repositories, issues, pull requests, and CI configuration, you are the controller and GitStache is the processor acting on your instructions. For the account, billing, and audit data GitStache needs to run the hosted service itself, GitStache is the controller. Where you are an enterprise customer, a separate Data Processing Agreement (see docs/DPA.md) governs the processor relationship and prevails over this policy on processor-specific terms.

2. The data we collect, and why

We collect only what the service needs to function. The categories below map to real systems; we do not maintain a separate marketing profile of you.

2.1 Account and identity data

When you sign up or are invited to the hosted service, our identity provider (WorkOS, see § 5) creates and stores an identity record. GitStache retains:

• A stable identity subject (the OIDC sub / WorkOS subject identifier) that uniquely identifies your login principal.
• Your email address.
• A last-login timestamp.
• Profile attributes surfaced by your login method (for example, display name and avatar, where the login provider supplies them).

Purpose / lawful basis: to create and secure your account, authenticate you, enforce access permissions, and contact you about the service. Lawful basis: performance of a contract (providing the service you signed up for) and our legitimate interest in securing accounts.

2.2 How we link your accounts (multiple sign-in methods, one account)

GitStache lets you sign in through more than one method (for example, an email login and a social provider) and resolve them to a single account of record. To do this we keep a local account-identities table that maps each distinct login principal (each provider subject) to your one account. For each linked identity we store the provider name, the identity subject, the email associated with that identity, and a record of how the link was authorized (the verification source, for example an email-verification flow or a trusted-domain match).

We link a new sign-in method to your existing account only when the link is authorized through a trusted verification path (for example, proven control of a verified email address). We do not silently merge accounts on the basis of a self-asserted email alone. Linking is an access-granting action: attaching a new identity to your account is equivalent to attaching a new credential, so it is gated accordingly.

Purpose / lawful basis: to give you a single coherent account across multiple sign-in methods without creating duplicate identities, and to keep account linking safe. Lawful basis: performance of a contract and legitimate interest in account integrity.

2.3 Session data

When you are signed in, we maintain a sealed session (an encrypted, authenticated session cookie issued via our identity provider's AuthKit sealed-session mechanism). The session cookie lets you stay logged in across requests without re-authenticating on every action.

Purpose / lawful basis: strictly necessary to keep you authenticated. Lawful basis: performance of a contract; this is a strictly-necessary cookie (see § 10).

2.4 Billing data (applies only if and when paid billing is enabled)

Paid billing is not currently active on the hosted service. When we enable it (see § 2.4's note below and the Terms of Service), billing is processed by Stripe (see § 5). GitStache stores, in association with your organization, the Stripe customer identifier, the subscription identifier(s), and your plan tier (Free, Premium, or Ultimate). We do not store your full card number; card data is handled by Stripe under its own PCI-compliant systems.

We also derive, for the purpose of per-active-user billing, a count of active users in a billing period (an active user is an organization member who performs at least one forge operation, such as a push, pull-request action, CI trigger, issue action, or permission change, in the billing month).

Purpose / lawful basis: to operate subscriptions and bill correctly. Lawful basis: performance of a contract.

Honest status note. As of the effective date, paid billing is switched off on gitstache.dev (BILLING_ENABLED is not set), no card is charged, and no live Stripe billing data is created for the hosted service. The billing terms above describe how the data will be handled once billing is deliberately turned on. Until then, this section is forward-looking.

2.5 Repository and code content

The core of the service is hosting the content you push and create: source code, commit history, branches, tags, pull requests, code review comments, issues, and related metadata.

This content may itself contain personal data that you or your collaborators put there, for example names and email addresses in commit author headers, or personal data written into comments, commit messages, issue bodies, or files. You are responsible for the personal data contained in the content you upload. GitStache stores and serves this content as you direct it; we do not inspect, validate, redact, or remove personal data embedded in your content, and we do not use your code content to build advertising or cross-customer profiles. If you need personal data removed from repository content or git history, you (the controller of that content) must make that change in the content itself, for example by rewriting history; we provide the platform to do so but do not do it for you unless separately contracted.

Purpose / lawful basis: to provide the hosting, review, and collaboration service. As processor, we act on your instructions; you as controller must have your own lawful basis for the personal data you upload.

2.6 Continuous-integration (CI) and build data

When you run CI jobs, we store build logs and job metadata. CI environment-variable values are never written to logs; only the names of environment variables may appear. Secrets you configure are never materialized into untrusted (for example, forked-pull-request) jobs. We record job parameters, timing, resource usage (for quota and, where enabled, overage metering), and the short-lived, repo-scoped credential identity a job used.

Purpose / lawful basis: to execute the CI you trigger, to meter usage against your plan, and to provide build logs for debugging. Lawful basis: performance of a contract.

2.7 Audit-log data

Every state-changing action on the hosted service is recorded in an append-only audit log. Each audit record captures:

• the actor identity (user, service, or system),
• the resource touched (for example a repository, pull request, issue, or secret),
• the action performed,
• a timestamp,
• the source IP address and user agent, and
• the result (success, denied, or error).

Audit records are written by construction and are not editable after the fact.

Purpose / lawful basis: security, incident investigation, abuse prevention, and (for enterprise customers) compliance and audit. Lawful basis: legitimate interest in operating a secure, auditable service, and, for enterprise customers, performance of the customer contract.

2.8 Notification and collaborator email data

To deliver invitations and notifications, we process the email addresses of users and of people invited to collaborate. Transactional email (invitations and operator notifications) is delivered via AWS SES (see § 5). We do not send marketing or bulk email through this path.

Purpose / lawful basis: to invite collaborators and notify users of activity they are party to. Lawful basis: performance of a contract and legitimate interest in enabling collaboration.

2.9 What we deliberately do NOT do

• We do not run third-party advertising or tracking pixels on logged-in surfaces.
• We do not enable AI features by default; any AI feature in the product is strictly opt-in and its output is labeled as AI-generated.
• We do not phone home with usage telemetry from self-hosted instances; a self-hosted instance sends nothing outside its boundary unless its operator explicitly opts in.
• We do not log CI secret values.

3. Cookies and sessions

GitStache uses a small number of cookies, all strictly necessary to operate the service:

• A sealed session cookie (encrypted and authenticated) to keep you signed in.
• Cookies required for security (for example, request-integrity / CSRF protection) and basic functionality.

We do not use advertising cookies, cross-site tracking cookies, or third-party analytics cookies on logged-in surfaces. Because our cookies are strictly necessary for a service you have asked us to provide, they do not require consent under the ePrivacy regime, but we disclose them here for transparency.

We do not use third-party analytics or advertising cookies anywhere on gitstache.dev, including on unauthenticated marketing pages. If that changes, this section will be updated to disclose the tool before it is enabled.

4. How we share data: subprocessors and third parties

We do not sell personal data. We share personal data only with the infrastructure and service providers ("subprocessors") that are necessary to run the hosted service, each under a data-processing agreement and each limited to the data it needs for its function.

4.1 Subprocessor list

A note on components you might expect to see but will not. Certain software GitStache uses (for example the Keycloak identity server and the OpenFGA authorization engine for self-hosted deployments, and the NATS event bus) runs on our own infrastructure, not as an external third-party processor of hosted-service personal data, so they are not listed as subprocessors. Content-delivery via Cloudflare is not engaged for the hosted service and is therefore not listed.

4.2 Social and enterprise login providers

If you choose to sign in through a third-party login (via WorkOS), you interact with providers such as Google, GitHub, GitLab, and LinkedIn (the exact set may change over time). Signing in through one of these providers shares your authentication with that provider under its privacy policy; GitStache receives only the identity attributes needed to establish your account (see § 2.1 and § 2.2).

4.3 Legal and safety disclosures

We may disclose personal data where required by law (for example, a valid court order or lawful government request) or where necessary to investigate and stop abuse, fraud, security incidents, or violations of our Terms. Where lawfully permitted, we will seek to notify the affected customer.

4.4 Business transfers

If Idiom Studios is involved in a merger, acquisition, financing, or sale of assets, personal data may be transferred as part of that transaction. We will require the recipient to honor this policy or provide notice and choice as required by law.

4.5 Changes to subprocessors

We will provide notice before adding a new subprocessor that processes hosted-service personal data.

5. Where your data is processed

Hosted-service data is processed primarily in AWS us-east-1 (United States). Continuous-integration jobs execute on dedicated hardware in Germany (European Union) provided by Hetzner. Identity processing (WorkOS), billing (Stripe, when enabled), and transactional email (AWS SES) occur in the provider regions noted in § 4.1.

This means your data may move between the United States and the European Union in the ordinary course of providing the service (for example, repository content is stored in the US and copied to the German CI executor for the duration of a build). International-transfer safeguards are described in § 6.

6. International data transfers

Because the hosted service processes data in the United States (AWS) and executes CI jobs in Germany / the EU (Hetzner), personal data is transferred across borders.

• EU/EEA/UK to US transfers (for example, an EU user's account or content processed in AWS us-east-1) rely on appropriate safeguards, principally the European Commission's Standard Contractual Clauses (SCCs) incorporated into our providers' data-processing agreements, together with supplementary technical measures (encryption in transit and at rest). We also rely on our providers' own compliance certifications (including EU-US Data Privacy Framework certification, where a provider holds one) as an additional safeguard layered on top of the SCCs.
• US to EU transfers (repository content sent to the German CI executor) keep the data within, or move it into, the EEA and are protected by the same contractual and technical measures.
• Data in transit is protected with TLS 1.3; data at rest is encrypted (see § 8).

7. Your rights

Depending on where you live, you have rights over your personal data. GitStache honors the following, and will not discriminate against you for exercising them.

7.1 Rights under the GDPR (EU/EEA/UK)

• Access: obtain a copy of the personal data we hold about you.
• Rectification: correct inaccurate or incomplete data.
• Erasure ("right to be forgotten"): request deletion of your personal data, subject to legal-retention exceptions (§ 9).
• Portability: receive your data in a structured, commonly used, machine-readable format.
• Objection: object to processing based on legitimate interests.
• Restriction: request that we limit processing in certain circumstances.
• Withdraw consent: where processing is based on consent, withdraw it at any time (without affecting prior processing).
• Lodge a complaint with your local supervisory authority.

Important scope note for content. Where you are an end user of an organization's account, much of the personal data about you sits in content and configuration controlled by that organization (the controller). For those requests we act on the organization's instructions; please direct content-level requests to the organization, and we will assist the organization in fulfilling them. For the account, billing, and audit data for which GitStache is the controller, contact us directly (§ 14).

7.2 Rights under US state privacy laws (CCPA/CPRA and similar)

If you are a resident of California or another US state with a comprehensive privacy law (for example Colorado, Virginia, Connecticut, Utah), you have rights to know/access, delete, correct, and opt out of "sale" or "sharing" of personal information, and to non-discrimination for exercising them. GitStache does not sell your personal information and does not share it for cross-context behavioral advertising. You may exercise these rights via the contact in § 14; we will verify your request against your account.

7.3 How to exercise your rights

Contact us using § 14. We will respond within the time required by applicable law (generally within one month under the GDPR, extendable where permitted, and within the statutory window under applicable US state law). We may need to verify your identity, typically by confirming control of your account, before acting.

8. How we protect your data

GitStache is engineered around a security model documented internally in docs/security-model.md. Without overstating our posture, the concrete controls include:

• Encryption in transit: TLS 1.3 for external traffic.
• Encryption at rest: the PostgreSQL metadata database and object storage are encrypted at rest; secrets are encrypted via cloud KMS and decrypted only at runtime for trusted jobs. CI secret values are never written to logs.
• Tenant isolation: the hosted database enforces row-level security keyed to your identity subject and organization, so a query cannot cross tenant boundaries by construction. Authorization is checked on every resource access via a relationship-based model.
• Authenticated sessions: logins use WorkOS AuthKit sealed sessions (encrypted, authenticated session cookies).
• Zero-trust CI: every CI job is treated as potentially hostile. Jobs run in isolated, single-use execution environments with a default-deny network posture and an explicit egress allow-list (an audited forward proxy), gVisor (runsc) sandboxing on the dedicated CI executor, no shared state between jobs, and short-lived, repository-scoped credentials that expire when the job ends.
• Append-only audit logging: audit records are written by construction and are not editable after the fact.

What we do not claim. GitStache does not currently hold a SOC 2, ISO 27001, or other third-party security certification, and this policy makes no such claim. No method of transmission or storage is perfectly secure; we work to protect your data but cannot guarantee absolute security. We describe our controls so you can assess them, not to imply a certification we do not have.

9. How long we keep data

We keep personal data for as long as needed to provide the service and to meet legal, security, and accounting obligations, then delete or anonymize it.

• Audit logs: retained for a default of 90 days; enterprise plans may retain for one year or longer where contracted.
• Account and identity data: retained for the life of your account; deleted or anonymized after account closure, subject to the exceptions below.
• Repository and CI content: retained while your account/organization keeps it; deleted after account or repository deletion.
• Billing records (when billing is enabled): retained as required by tax and accounting law.
• Backups: deletions propagate to backups on the backup-rotation schedule rather than instantly.

Exceptions. We may retain data longer where required by law (for example a legal hold, regulatory requirement, or tax obligation) or in anonymized form for legitimate business purposes such as service improvement.

10. Children

GitStache is not directed to children. The hosted service is intended for users who are at least 16 years old in the EU/EEA (or the applicable digital-consent age in your country) and at least 13 years old in the United States. We do not knowingly collect personal data from children below these ages. If you believe a child has provided us personal data, contact us (§ 14) and we will delete it.

11. Automated decision-making

We do not make decisions producing legal or similarly significant effects about you based solely on automated processing. AI features, where offered, are strictly opt-in and clearly labeled (§ 2.9).

12. Self-hosted deployments

If you run GitStache yourself, the personal data on your instance is processed on your infrastructure, and you are its controller; this policy's hosted-service processing does not apply. The one Idiom Studios interaction designed for self-hosted paid deployments is license validation, and it is built to run fully offline: the appliance verifies a signed license file locally against a key embedded in the software and does not phone home. GitStache does not receive your instance's user data, repository content, or usage telemetry through the licensing mechanism.

13. Changes to this policy

We may update this policy as the service and the law evolve. When we make a material change, we will update the "Last updated" date and, for significant changes affecting the hosted service, provide reasonable notice on gitstache.dev. Where the change materially affects how we handle personal data and the law requires it, we will seek your consent. Our broader governance pledge (see GOVERNANCE.md) commits us to advance notice on material model and terms changes.

14. Contact

For privacy questions or to exercise your rights, contact:

• Privacy / data-protection contact: getgitstache@gmail.com
• Security incident reports: getgitstache@gmail.com

15. Counsel-review status

This Privacy Policy was drafted by an AI agent from GitStache's internal architecture, security, and governance records and is accurate to the product as built, but it has not yet been reviewed by qualified privacy counsel. It should be reviewed by a licensed privacy attorney before it is relied upon or presented to users as final. Consistent with our standing posture, that counsel review runs in parallel and does not block the product; until it completes, we recommend carrying a short visible caveat on the published page (for example: "This policy is current and accurate to how GitStache works; a formal legal review is in progress.").

This document is maintained at docs/legal/privacy-policy.md and mirrored into the public privacy page on gitstache.dev.