Skip to content
Since.dev
CalendarScannerDocsPricing
Sign inStart free

Last updated October 26, 2026

Privacy

Since.dev tracks public packages, APIs and AI models, and analyzes the repositories you connect or scan. This page explains what we collect, what we keep, who processes it and how to delete it.

On this page

  1. The short version
  2. Who is responsible
  3. What we collect and why
  4. What we keep from your code
  5. Models and your code
  6. Shared answers
  7. Pull requests
  8. The public scanner
  9. Why we process it
  10. Processors
  11. International transfers
  12. Security
  13. Retention
  14. Your rights
  15. Cookies and analytics
  16. Children
  17. Changes
On this page
  1. The short version
  2. Who is responsible
  3. What we collect and why
  4. What we keep from your code
  5. Models and your code
  6. Shared answers
  7. Pull requests
  8. The public scanner
  9. Why we process it
  10. Processors
  11. International transfers
  12. Security
  13. Retention
  14. Your rights
  15. Cookies and analytics
  16. Children
  17. Changes

The short version

  • Since.dev tracks packages, APIs and AI models from public sources. That record is public fact with no account identifier on it. It analyzes only what you connect or scan: your repositories, the code you send through the API or MCP, and public repositories you scan.
  • Your source code is not stored durably. Files are held only while they are analyzed and are deleted when the analysis ends. What we keep is an inventory of your dependencies and a record of use: for each file, the packages, APIs and models it names, and the lines where.
  • Strings and configuration lines that look like secrets are dropped before they are stored. Code sent to a model is sent as it is in your repository, so keep credentials out of source.
  • Code goes to Anthropic only to check whether a change affects your code and to write the fix. We do not train models on your content, and Anthropic’s commercial terms say it does not train on data sent through its API. See models.
  • Since.dev builds and checks each fix before it opens the pull request, opens it ready for review, and never merges or deploys. You can pause a repository or opt out of a fix at any time. See pull requests.
  • Removing a repository stops its tracking at once, and what we hold for it is deleted 30 days after removal, as described under retention.
  • Scanning a public repository without signing in stores only public data, for its share link. See the public scanner.
  • Export and deletion are self-service from Settings for the account owner. Before deleting your login, leave invited teams, delete additional workspaces you own, and remove other members and pending invitations from your primary workspace. Deleting an additional workspace preserves your login and other workspaces. What you delete is deleted 30 days after removal.
  • This website counts visits with Google Analytics, but only if you accept it. There is no advertising network, and nothing follows you to other sites. See cookies and analytics.

Who is responsible

Since.dev is responsible for account, billing and service-operation data. For repository content a business customer asks us to process within its workspace, we act on that customer’s instructions, subject to any applicable data-processing agreement. Our postal address is 131 Continental Drive, Suite 305, Newark, DE 19713, United States. For any privacy question or request, write to privacy@since.dev. We answer every request, including the ones we have to refuse, and we say why.

What we collect and why

Your account

Your name and email address, and either a password or the identity your sign-in provider returns. With GitHub sign-in that is your GitHub account id, login, name, email address and avatar, and the tokens the provider issues for sign-in. Each session records the device and address you signed in from. We also keep the members and invitations of a workspace, and the notification settings you choose. We use it to sign you in and run your workspace.

Billing and usage

Billing and payments, including prepaid balance purchases, run through Stripe. Since.dev stores a customer reference, your plan, and each prepaid balance purchase with its amount, the date it was bought, the date it expires and how much of it is used, never card numbers. Each API or MCP call is recorded for the workspace with its endpoint and the credits it used, and each fix pull request counts against the month’s allowance. We use these records to meter your plan and to answer billing questions.

Since API keys

A Since API key is shown once, when you create it. Only a one-way hash of it is stored, so a lost key is replaced rather than recovered, and we cannot read your key back to you.

GitHub installation and repositories

When you install the Since.dev GitHub App we store the installation (the account, its permissions and its status) and the list of repositories it can see: name, id, default branch, whether each is private and whether it is archived. When you connect an organization we read your own membership once, to confirm that you are an owner. Installation tokens are made for one operation, limited to the repository and permissions it needs, and never stored. From GitHub webhooks we keep identifiers, states and logins, such as the outcome of a CI run or whether a push was forced, and never commit messages or file contents. We use this to analyze your repositories and to open pull requests in them.

Repository files

To find what your code depends on and uses, Since.dev reads from each connected repository its manifests and lockfiles, its configuration files and its source files. It reads example environment files such as .env.example and never real .env files. Reading them runs none of your code. To build a fix before it opens the pull request, Since.dev copies the repository into a single-use, isolated machine made for that one fix, installs it and runs your project’s own build and checks with the change. That machine holds no Since.dev credentials, reaches only public package registries and the public hosts packages and language toolchains download from, and is deleted with everything in it when the fix ends. What Since.dev does with these files is described under what we keep.

Requests to the API and MCP

A request carries an input: a model ID or package version, a code snippet, the contents of a manifest or lockfile, or a repository. We use it to answer the request. We do not store the snippet, the manifest or the lockfile after the response, or a patch returned for it. We keep a record of the call: when it happened, which key or MCP client made it, which endpoint, the credits it used and the outcome. A repository you ask about is read as described under what we keep.

Where you asked us to deliver

The email addresses you choose for notices, and the webhook endpoint URLs you add, with a signing secret for each webhook and a delivery record for each attempt: status code, timing, and whether it was retried or stopped after repeated failures. Delivery records are operational data about your endpoint, not about you. Signed webhook receivers process the data you direct to them under your own arrangements.

Support and feedback

What you write to us, and the feedback you send from the app. We use it to answer you and to improve the product.

What the sources said

Facts read from public sources, such as a release, a deprecation or a retirement date, are stored without an account identifier. They describe a public record, not you, so they are not personal account data and are not part of an account export.

Technical logs

Request metadata for the API and the website: timestamp, route, response status, approximate location derived from the IP address, and the IP address itself. These exist for reliability, rate limiting and abuse investigation. They are kept for 30 days. They are not used to build a profile of you.

What we keep from your code

This is the part that matters most, so it is stated plainly: Since.dev reads your code to find what it uses, and keeps the finding, not the code.

Repositories you connect

  • The inventory. Every dependency a repository declares or locks: packages, runtimes, container images and GitHub Actions, with the ecosystem, the declared range, the resolved version, whether it is direct, its scope (runtime, dev and so on) and the file that declared it.
  • The record of use. For each file that uses a tracked package, API or model: the file path, the line number, the package, API or model it names, the symbol, the shape of the call (how many arguments and which keyword names) and the values that matter, such as a model ID, an API host or an endpoint path. We also keep which files import which.
  • Per-file results. The same findings for each file, saved so that a file that has not changed is not read again. They are kept with our file storage provider (see processors), encrypted at rest, and are not copies of your files. Each workspace’s results are kept apart, so one workspace cannot learn that a file exists in another.
  • Impacts. Each change that affects a repository, with the file, line, severity, days left, the public evidence for the change and a short explanation. An impact does not keep copies of your lines. The explanation can name functions or values from your code.
  • Fix records. The one place we keep code. When Since.dev writes a fix, we keep the patch (the lines it changes, with a few lines around them), the commands it ran to build and check the fix with short excerpts of their output (secrets removed), the pull request number and link, the review and CI results, and the activity on it, so you can review and revise it. The same lines are in the pull request on GitHub.

All of this is private to your workspace. It is not shared with other workspaces and does not appear in public pages, in the public scanner or in shared answers.

The files themselves are not stored. They are held only while they are analyzed and deleted when the analysis ends.

Before they are stored, string values and configuration lines are screened for secrets such as keys and tokens. A value that looks like a secret is dropped and never stored. A patch is screened the same way before its pull request opens. Screening limits collection but cannot guarantee that a sensitive value never appears in a result. It does not cover the code a model reads (see models), so do not commit credentials to source files.

Removing a repository, removing the GitHub App or deleting your workspace stops its tracking at once, and what we hold for it is deleted 30 days after removal, as described under retention. It does not delete pull requests or branches already on GitHub.

Models and your code

We use AI to check whether a change affects your code, to write and review fixes, and to explain the result.

To check an impact, Since.dev sends Anthropic the code around the use it found, and related code it needs to understand that use, with the change and its evidence. To write a fix, it sends the files it edits and the code that calls them, any other repository files it reads, and the output of the commands it runs to build and check the change. To revise a fix, it also sends your comment on the pull request and, when CI failed, the failing job’s log. Code you send through the API or MCP is handled the same way. Checking impact uses AI on every plan; fixes are written on Team and up. The public scanner sends no code to a model.

Code, comments, logs and command output are sent as they are in your repository, on GitHub or in the fix’s machine. The secret screening described above applies to what we store, not to what a model reads, so keep credentials out of source files and out of CI and build output.

We do not train models on your content. Under Anthropic’s commercial terms, Anthropic does not train its models on data sent through its API, and it handles that data as those terms and its privacy policy describe. A workspace cannot connect an AI provider of its own.

Findings cite the evidence used, but a model can be wrong or incomplete. A citation is not a guarantee of accuracy.

Shared answers

Many repositories call the same package in the same way. When a question about a change is made only of public facts, Since.dev answers it once and reuses the answer for every workspace.

  • What goes in. Only public facts: the package, the function or class used, argument names from the package’s public signature, and a value only when it is already public, such as a known model ID or a public API host. No other value from your code is used.
  • What comes out. One of affected, not affected or depends on your code, and the name of a public argument. Never free text.
  • What is never shared. Your code, file paths, repository and workspace names, and the explanation shown with an impact. When the answer depends on your code, it is checked for your repository alone and never shared.
  • Where an answer came from is never shown. Not to you about other workspaces, and not to them about you. There is no count of repositories behind an answer.

A workspace owner can opt out in Settings, or by writing to privacy@since.dev. A workspace that opts out neither uses nor adds to shared answers, so its impacts are checked for it alone where its plan allows. On Free, a repository is checked alone only for critical changes, and the other impacts show as needing review. Answers already shared contain no workspace identifier and stay.

Pull requests

On Team and up, Since.dev opens a fix as a pull request from a branch it creates, ready for review and labeled since, after it has built the fix and run your project’s own checks with it. When it cannot build a repository, the pull request says so and leaves the check to your CI; with no CI there, it opens none and says why. It never merges, never deploys and never changes branch protection, secrets or cloud resources. Your CI runs in your repository and people decide whether to merge. Free shows impacts and opens none.

The pull request, its branch and its commits are written to GitHub under your installation, so GitHub and anyone with access to the repository can read them. The description says what changed and why, how severe it is and how many days are left, lists each edit with its source, and tells you how to opt out.

To stop pull requests, pause a repository on its page, switch off a single change, dismiss an impact (which closes its pull request), remove the repository, or remove the App on GitHub.

A comment you write on a pull request that Since.dev opened is read as an instruction for a revision and kept with the fix record. When CI fails on one, Since.dev reads the failing job’s log once to revise the fix. Comments and logs on pull requests it did not open are not used.

The public scanner

Anyone can scan a public repository without signing in. Since.dev reads the repository’s public code, matches it against what changed and shows the result. It sends no code to a model.

It stores the result so the share link works: the repository’s owner and name, the files and lines where it found a use, the packages, APIs and models, and what changed, with its severity, date and source. Everything in it is already public. The page is not indexed by search engines, but anyone with the link can read it. If you own a repository and want a result removed, write to privacy@since.dev and we will remove it.

To limit abuse, scans are counted per visitor per day using your IP address (for IPv6, its /64 network). The address is kept in a rate limit record for about a day. The retirement calendar pages are public, and their scan box works the same way.

Why we process it

Where the GDPR or a similar law applies, these are the grounds we rely on:

  • To perform our contract with you: creating and running your account, reading and analyzing the repositories you connect, checking impact, opening the pull requests you are entitled to, answering API and MCP requests, delivering notices and webhooks, and taking payment.
  • Our legitimate interests: keeping the service up, preventing abuse and fraud, enforcing plan limits, running the public scanner within its daily limit, and reusing answers made only of public facts. We use the minimum data each of those needs.
  • Legal obligation: keeping invoices and tax records for the period the law requires.

Processors

Our service providers and connected platforms support the purposes below. Hosting and service providers process data for our operations; platforms you connect also process data under your account’s terms.

ProcessorPurpose
VercelHosting and delivery for the public website and the application console, and their request logs; running each fix's build and checks in a single-use, isolated environment that is deleted when the fix ends.
Fly.ioHosting for the Since.dev API and the service that analyzes your repositories, including repository files while they are analyzed, and their operational logs.
GitHubGitHub sign-in when you choose that authentication method, authorized repository access, app installation metadata, your own organization membership to confirm you are an owner, the webhook events Since.dev reads, branches and pull requests, review feedback, and repository check results.
Amazon Web ServicesEncrypted file storage for the per-file results kept from your repositories, not the files themselves.
SupabaseDatabase hosting for account, workspace and billing records, and what we keep about your repositories: dependencies, record of use, impacts and fix records.
AnthropicAI processing: the code around a use a change may affect, and the files a fix edits, with the change and its evidence, to decide whether your code is affected and to write the fix; when a fix is revised, your pull request comment and the failing CI log. Used on every plan.
StripeSubscription checkout, prepaid balance purchases, billing, and payment processing.
ResendTransactional email: password resets, change and impact notices, team invitations, and credit alerts to the workspace owner.
GoogleGoogle sign-in when you choose that authentication method, and Google Analytics traffic measurement on the public website.
MicrosoftMicrosoft sign-in when you choose that authentication method.

We will announce a new processor by email before it starts handling personal data, so that you have time to object or to leave.

International transfers

Our processors operate in the United States and, in some cases, elsewhere. Where personal data leaves the European Economic Area, the United Kingdom, or Switzerland, the transfer is covered by the European Commission’s Standard Contractual Clauses or another lawful mechanism. A copy of the relevant terms is available from privacy@since.dev.

Security

  • Traffic is encrypted in transit, and stored data, including the per-file results, is encrypted at rest.
  • Since API keys are stored only as one-way hashes. Passwords, where used, are stored only as salted hashes; we never store a password in a readable form. Card details never reach our systems.
  • GitHub installation tokens are made for one operation, limited to the repository and permissions it needs, and never stored. Your code runs only in the single-use machine that builds its own fix, never on the machines that hold your data or our credentials, and nothing of the repository is kept from that machine beyond the fix record. There your project’s package manager asks the public registries for the packages it installs, which names those packages to each registry.
  • Access to production data is limited to the people who need it to operate the service.
  • Webhook deliveries are signed with your endpoint’s secret and a timestamp, so you can verify that a delivery came from us and was not replayed.

No system is perfectly secure. If a breach affects your personal data we will notify you and the relevant regulator within the time the law requires, with what we know and what we are doing about it. To report a vulnerability, write to security@since.dev.

Retention

  • Account data, workspace settings, API keys, webhook delivery records and the record of the calls you made are kept while your workspace is open.
  • The inventory, the record of use, the per-file results, impacts and fix records for a repository are kept while it is connected. Removing the repository, removing the GitHub App or deleting the workspace stops its tracking at once, and all of them, including the per-file results in file storage, are deleted 30 days after removal. Until then a removed repository or workspace can be restored with its history. The workspace’s use of credits and fix pull requests this month is not repository data. It stays counted, so reconnecting does not reset it. Pull requests and branches already on GitHub stay there.
  • A removed webhook endpoint receives nothing from the moment it is removed, and it and its delivery records are deleted 30 days after removal.
  • Repository files read for an analysis are deleted when the analysis ends.
  • GitHub webhook deliveries are deleted seven days after they are processed.
  • Public scanner results are kept so share links keep working, and are deleted on request.
  • Deleting your account signs you out at once and stops sign-in. Your account, API keys, repository data, notification settings and webhook endpoints are deleted 30 days after removal; until then, write to us to restore them. Public-source facts and shared answers, which carry no account identifier, may remain because they do not contain personal data about you.
  • Technical logs are kept for 30 days and then deleted. Rate limit records keep an address for about a day.
  • Prepaid balance purchases are deleted with the workspace they belong to, and an unused balance is lost. Invoices and tax records, which Stripe keeps, are kept for as long as accounting and tax law requires, which is longer than the rest.

Your rights

Export and deletion are self-service in Settings for the account owner and do not require you to ask us. Before deleting your login, leave invited teams and remove other members and pending invitations from your owned workspace. Depending on where you live, you may also have the right to access your data, correct it, restrict or object to how we use it, withdraw consent, and receive it in a portable format.

We do not sell personal information, and we do not share it for cross-context behavioural advertising, as those terms are used in California law. We have never done either, so there is no opt-out to offer you. We will not discriminate against you for exercising a right.

Write to privacy@since.dev and we will respond within the period the applicable law sets. If you are in the EEA, the UK, or Switzerland and you are unhappy with our answer, you can complain to your local supervisory authority.

Cookies and analytics

This website uses Google Analytics 4 to count visits and see which pages get read, but only after you accept it in the bar shown on your first visit. Until you accept, nothing from Google loads and no analytics cookie is set. If you decline, that stays so. Once you accept, it sets first-party cookies named _ga and _ga_<ID>, and reports the pages you view, the site that referred you, your device and browser type, and an approximate location that Google derives from your IP address without retaining the full address.

It is used to understand traffic, and for nothing else. It is not advertising, it is not linked to your account or your repositories, it is not sold, and it does not follow you to other websites. Separately, Since.dev counts product milestones in its own records, such as connecting a repository, the first analysis, opened and merged pull requests, and upgrades. These records carry a workspace identifier, the plan and, when you signed up from a public change page, which page, but no code, repository names or request inputs. They measure whether the product is useful and are not sent to Google Analytics.

We keep your choice in your browser’s local storage, so we do not ask again, and you can change it at any time with Analytics choice in the footer. Declining costs you nothing here, because no part of this site depends on analytics. You can also block the script with a browser setting or extension, or with Google’s own opt-out add-on.

Apart from analytics, the app uses necessary cookies for sign-in and sessions, and one preference cookie, sidebar_state, that remembers whether the app’s sidebar is open. Blocking the necessary cookies prevents authenticated use of the app. There is no advertising cookie anywhere in the product.

Children

Since.dev is a tool for developers and professionals. It is not directed to children, and we do not knowingly collect personal data from anyone under 16. If you believe a child has given us data, write to privacy@since.dev and we will delete it.

Changes

Material changes to this page will be announced by email before they take effect, and the date at the top will change. General questions: hello@since.dev.

The changelog of the internet.

Product

  • Scanner
  • Calendar
  • How it works
  • Pricing
  • FAQ

Guides

  • All guides
  • Dependency breaking changes

Developers

  • Docs
  • Quickstart
  • HTTP API
  • MCP server
  • Webhooks
  • llms.txt

Public data

  • Sources

Company

  • Privacy
  • Terms
  • Contact
  • Security
since.dev

© 2026 Since.dev