Security at TrimCI

TrimCI is built around one promise: we analyze your CI/CD pipelines without ever asking for access to your repository. This page describes, in concrete terms, what we access — including the one honest caveat about job logs in section 1 — how we protect it, and where your responsibilities begin. We would rather show you specifics than badges.

1. What we never access

We never read your source code, workflow YAML files, commit diffs, or any repository file. Our GitHub App requests only two read-only permissions (Actions and repository metadata) — never repository contents. GitLab's API offers no scope that narrow, so we enforce the boundary ourselves: a runtime allowlist inside our HTTP clients rejects any data request outside pipeline, job, project-listing, and connection-setup (identity, version and token-status) endpoints before it leaves our servers. Extending that allowlist requires a deliberate code change, and automated tests enforce it — an accidental request into repository contents is rejected in software before it is ever sent. One honest caveat: a job log is your build’s console output, so if a build prints a stack trace, a file path or a snippet of a config file, that text reaches us inside the log excerpt. We never fetch it from your repository — but we will not pretend a log tail is guaranteed to be free of code.

2. What we do process

• Account data: your email address and a salted password hash.
• Pipeline metadata: run and job names, timing, durations, statuses, conclusions, branches, trigger events, and the username of the person who triggered each run.
• Failed-job log excerpts: the last 8,000 characters of unsuccessful jobs only (failed, timed out, failed to start, or cancelled), stored compressed, automatically deleted after 30 days (retention details in section 7).
• Web analytics: cookie-less, self-hosted page-view records on our own EU servers — no raw IP stored, irreversible daily-rotating visitor identifier, no third-party analytics vendor.
• Product-milestone events: records that an account or organization reached a service milestone (e.g. first sync, first report); detached from the account on deletion.

Account-side operational data (technical server logs, billing identifiers, support correspondence) is inventoried, with retention periods, in the Privacy Policy.

3. Hosting and infrastructure

The service runs on Hetzner infrastructure in the European Union. The application, databases, queues and the AI model live in the same isolated environment; databases are not exposed to the public internet. All storage and processing performed by TrimCI happens in the European Union — see the sub-processor list. To collect CI data, our servers make API requests to the provider platforms your organization connected (GitHub is operated from the United States), carrying only the credentials and repository/run identifiers needed to read pipeline data. Physical and data-center security is the responsibility of our hosting provider, Hetzner, whose data centers are ISO/IEC 27001 certified. We run a single-region EU deployment without a formal uptime SLA; data collection is server-side and cursor-based, so after any downtime syncs resume where they left off.

4. Encryption

• In transit: all traffic — browser to TrimCI, and TrimCI to provider APIs — uses TLS.
• At rest: CI provider credentials (GitLab tokens) are encrypted with Fernet (AES-based) before storage; GitHub access uses short-lived installation tokens (60-minute lifetime) that are briefly cached server-side and never stored in the database.
• Credentials hygiene: authorization headers are redacted from logs; passwords are stored only as salted hashes.

5. AI processing — self-hosted by design

Optimization recommendations are generated by a language model hosted on our own infrastructure. Your logs and pipeline data are never sent to OpenAI, Anthropic, or any external AI provider. Before a log excerpt reaches the model, known secret formats (cloud keys, provider tokens) are redacted on a best-effort basis.

6. Access control

Every account requires email verification. Data is isolated per organization, and the organization context is validated on every request — a user can only ever see data of organizations they belong to. Management actions (connecting providers, selecting repositories, generating recommendations) are restricted to owner and admin roles. TrimCI is operated by its founder and production access is not shared; customer data is accessed only to operate the service, investigate a problem, or answer your support request.

7. Data retention and deletion

8. Your responsibilities

• Grant least scope: use the read_api scope for GitLab tokens (group tokens recommended), and install the GitHub App only on the repositories you want analyzed.
• Keep organization membership current: remove members who leave your team, and rotate provider tokens on offboarding.
• Protect your account credentials; TrimCI will never ask for your password by email.
• Avoid printing secrets or personal data in CI logs — log excerpts of unsuccessful jobs reach the service (with secret redaction as a safety net, not a substitute).

9. Reporting a vulnerability

If you believe you have found a security vulnerability, email office@trimci.com with "SECURITY" in the subject. We will not pursue legal action against good-faith research that respects user data and does not disrupt the service. Our machine-readable security contact is published at /.well-known/security.txt. Please keep testing in scope: no denial-of-service or volumetric testing, and never access data of organizations that are not your own.

10. Incident response

If we become aware of a security incident affecting your data, containing and investigating it takes priority over everything else. We notify affected organizations without undue delay, with the information they need for their own GDPR obligations — the nature of the breach, its likely consequences, the measures taken, and a contact point — as committed in Section 12 of our Data Processing Agreement. Notifications go to organization owners and admins by email.

11. Compliance posture

We are GDPR-first: an EU-registered business, EU-only hosting and processing, a public Privacy Policy, a self-serve Data Processing Agreement that applies to every organization automatically, and a published sub-processor list. We do not currently hold a SOC 2 attestation — at our size we invest in the concrete measures on this page instead, and this page is kept current as the service evolves. Our sub-processor list is deliberately minimal — EU-based providers bound by data-processing agreements, with additions announced by email at least 30 days in advance; web analytics and AI stay self-hosted precisely to avoid adding vendors. The software itself is developed against an automated test suite that includes tests enforcing the zero-code-access allowlists and the secret-redaction patterns described on this page, and dependencies are pinned to exact versions.

12. Changes and contact

Material changes to our security posture are reflected here with an updated date. Security questions: office@trimci.com.