SDK License & Open Integration

VibePing has two parts: a small JavaScript SDK that runs in your users' browsers, and a hosted cloud that turns those events into dashboards, funnels, and AI insights. They have different licenses, and the difference matters.

This page explains what that split means in practice — what you can do with the open-source SDK, what the hosted cloud covers, and why we chose this shape instead of going all-open or all-closed.

The short version

@vibeping/sdk is MIT licensed↗. Use it anywhere. Inspect the source. Ship it in a commercial product. Fork it. The whole thing is about 5KB of TypeScript — there is nothing to hide.

The hosted VibePing Cloud — the dashboard, AI explanations, funnel analysis, alerts, team features — is proprietary and runs at vibeping.dev↗. That is how we pay for the servers and the people building it.

That's it. The SDK is open, the intelligence is hosted.

If you want the tl;dr in a table:

Why this split

Developers have to trust the code that collects their users' data. When you drop a script tag into production, you are giving that code access to every URL, every error, every custom event your users trigger. You should be able to read it. You should be able to audit it. You should be able to ship it without a lawyer's approval.

So that part is open.

The analysis layer is different. That is where we actually add value — detecting anomalies, explaining errors in plain English, spotting funnel drop-offs, suggesting fixes. It is also where we incur costs: compute, storage, model inference, on-call rotations. That part is hosted.

The rule of thumb we landed on:

Open the part developers need to trust; sell the part they need to win.

What you can do with the SDK

Because @vibeping/sdk is MIT, you can:

• Read the source. It lives at github.com/Vibeping/vibeping↗. Go look.
• Install it from npm. npm install @vibeping/sdk. That's the same package the script tag loads.
• Ship it in closed-source commercial products. MIT explicitly allows this. You do not need to open-source your app.
• Modify and fork it. Patch a bug, add a feature, strip out something you don't want. The MIT license asks only that you keep the copyright notice.
• Redistribute it. Bundle it into a starter kit, a boilerplate, or another SDK.
• Point it at any backend. The apiUrl option is configurable. If you want to send events to your own endpoint for debugging, testing, or a totally different backend, you can.

import { init } from '@vibeping/sdk';
 
init({
  id: 'vp_your_key',
  apiUrl: 'https://your-backend.example.com', // optional override
});

The SDK does not phone home. It does not check a license key. It does not refuse to run if it cannot reach vibeping.dev. It is a dumb, honest event transport.

What MIT actually means in practice

If you have never read the MIT license↗ itself, it is extremely short — shorter than this paragraph. In practical terms it means:

• You can use the code for anything, including commercial products.
• You must keep the copyright notice if you redistribute the source or a substantial portion of it.
• There is no warranty. If the SDK breaks in production, that is on you — same as any other dependency.

That is the entire deal. There is no "you must share your changes," no "you must disclose your source," no "you must pay us above $X in revenue." It is the same license that Rails, React, jQuery, and most of the JavaScript ecosystem use.

What VibePing Cloud gives you

The hosted side at vibeping.dev↗ is where the interesting work happens:

• Real-time analytics dashboard — pageviews, sessions, errors, Web Vitals, broken down by page, referrer, device, country.
• AI error explanations — every error gets a plain-English summary and a suggested fix prompt you can paste into Cursor, Lovable, or Bolt.
• Funnel analysis and goal tracking — define a funnel with one sentence ("users who sign up then upgrade") and we build it.
• Anomaly detection and alerts — we tell you when something breaks before your users do.
• Team collaboration — shared projects, roles, comments on events.
• Managed infrastructure — no database to run, no ingestion pipeline to scale, no dashboards to deploy. You ship the SDK and open the dashboard.

None of this is in the open-source repo, and we are not planning to open-source it. That is the deal.

License history

It is worth being straight about how we got here.

• Before v0.2.0: the SDK was licensed under AGPL-3.0↗. AGPL is a strong copyleft license — it requires that anyone who modifies the code and runs it as a network service also publishes their modified source. That is a fine license for some projects, but it turned out to be the wrong choice for an instrumentation SDK. It made people nervous about dropping VibePing into commercial apps, even though the practical risk was small.
• From v0.2.0 onwards: MIT. Maximally permissive, universally compatible, zero friction.

Existing 0.1.x installs remain under AGPL-3.0. Licenses are not retroactive and we are not going to pretend otherwise. If you have AGPL 0.1.x running in production today, it is still AGPL 0.1.x — you can keep running it indefinitely under those terms. When you upgrade to 0.2.0 or later, you pick up the MIT license for that version going forward.

Nothing you have already shipped is affected. Nothing is revoked. No surprise audit emails.

If you are on 0.1.x and you want the MIT terms, the upgrade path is just:

npm install @vibeping/sdk@^0.2.0

The public API is the same — init, track, identify, flush, destroy. There are no breaking changes between 0.1.x and 0.2.x other than the license. See the Migration Guide if you want a checklist.

No self-hosting

This is the other question we get, so let's answer it directly: we do not support self-hosting the VibePing dashboard.

• We do not ship a Docker Compose file.
• We do not publish a self-host guide.
• We are not going to write one.

The SDK being open source does not mean the whole product is open source. You can read and modify the ingestion client all you want — that part is yours. The dashboard, database schema, AI pipeline, billing, and ops are ours, and they are designed to run as a hosted service.

If you were hoping to stand up your own VibePing instance on a VPS, this is the point where we say: sorry, that is not the product. If you are evaluating VibePing Cloud, sign up at vibeping.dev↗ — the free tier is generous, and there is no credit card required to try it.

If you need an instrumentation layer but want to run the whole pipeline yourself, there are good open-source analytics projects out there. We will cheerfully point you at them. VibePing Cloud is for teams who would rather pay a subscription and skip the ops work.

But the SDK is open — can't I just build my own backend?

Yes, actually. Nothing stops you.

The SDK sends batched JSON to whatever URL you configure in apiUrl. The payload shape is documented in the SDK Reference and the API Reference. If you want to point it at a tiny Node server you wrote yourself, a Postgres row inserter, or a log file, go for it. That is a legitimate use of an MIT-licensed library and we are not going to be weird about it.

What you would be building at that point is a custom analytics backend that happens to use our SDK as the ingestion client. That is fine — it is just not VibePing Cloud, and we cannot help you run it.

Contributing

Contributions to the SDK are welcome. The repo lives at github.com/Vibeping/vibeping↗ and there is a CONTRIBUTING.md at the root with the specifics — how to run tests, how we handle PRs, what the review expectations are.

A few things worth knowing up front:

• Contributions are MIT. By opening a PR against the SDK repo, you are agreeing that your contribution is licensed under MIT, same as the rest of the code. There is no separate CLA.
• Keep PRs small. The SDK is intentionally tiny. A change that doubles the bundle size is going to get a lot of questions.
• Bug reports are contributions too. If you hit something weird, open an issue with a minimal reproduction. That is genuinely helpful.

The examples directory — examples/nextjs-app-router, examples/nextjs-pages, examples/react-vite, examples/vanilla-js — is also part of the open-source repo and is also MIT-licensed. PRs against those examples are welcome, especially if you have a framework or a setup we have not covered yet.

Questions

If something in this page is unclear — or if you have a specific licensing question about how the SDK fits into your product — contact support from inside the dashboard↗ and we will get back to you. We respond fast, and we are happy to answer licensing questions in writing so you have something to show your legal team.

A few things we get asked a lot:

• "Can I use VibePing in an app I sell to customers?" Yes. MIT allows commercial use with no royalty and no revenue cap.
• "Do I need to credit VibePing in my app?" No. The MIT notice only needs to stay in the source files and the npm package — it does not need to appear in your user-facing UI.
• "Will you ever change the SDK license again?" We have no plans to. The move to MIT was deliberate and we would like it to be the last license change we ever make.
• "What about the examples directory?" Also MIT. Copy any of them into your own project without attribution if you want to.

For everything else, the Getting Started guide is the fastest way in, and the Framework Examples page has copy-paste snippets for Lovable, Bolt, Next.js, and plain HTML.