Pulsy is open source, and it means what you think it means
The whole application is on GitHub under AGPL-3.0-or-later. Not a demo, not a stripped community edition, not a source-available licence with a commercial-use clause bolted on. The code that runs pulsy.org is the code you can clone.
Browse the sourceWhat AGPL-3.0 gives you
The four freedoms, in the terms that matter for a piece of monitoring software.
Run it
For any purpose, commercial included, on as many hosts and for as many monitors as you like. No seat count, no usage reporting.
Study it
Every line, including the check scheduler and the crypto that protects provider credentials. Security you cannot inspect is a promise, not a property.
Modify it
Fork it, rip parts out, wire in a notification channel nobody else wanted. You do not need permission and you do not owe an explanation.
Share it
Redistribute the original or your modified version. Anyone you give it to gets these same freedoms — that is the part copyleft protects.
The obligation in return: if you distribute a modified Pulsy, or run one as a network service others use, those users must be able to get your modified source. That is the difference between the AGPL and a permissive licence, and it is deliberate — it keeps improvements reaching everyone. Full text: AGPL-3.0-or-later
No tiers, no gated capabilities
The self-hosted build has every feature on. Not a generous subset — all of it: every notification channel, public status pages with custom domains, TLS-expiry alerting, incident grouping, SLA reports, the full REST API, and every locale. There is no monitor cap, no check-interval floor imposed by licence, and no upgrade prompt anywhere in the product.
Two build-time flags exist in the codebase, and they configure a deployment rather than sell features: one controls whether open-source surfaces appear, the other whether Pulsy Cloud's plans and billing UI are wired up. A self-hoster leaves them at their defaults and never encounters a gate.
So what is Pulsy Cloud, then?
The honest version, because open-core projects usually leave this vague.
Pulsy Cloud is hosting. It runs the same AGPL-3.0 code on infrastructure operated by Pulsy, with backups, upgrades, and uptime as someone else's problem. The plans differ on scale and operational limits — how many monitors, how tight the check interval, how long history is kept, how many seats — because those consume resources that cost money to provide. They do not differ on which features you may use.
What Cloud will not become: a reason to hold features back from the open-source build. If a capability ships in Cloud, it ships in the repository. If that ever stops being true, the licence is what gives you the right to fork and carry on — which is rather the point of choosing it.
Contributing
Bug reports and translations are as welcome as pull requests. Start with these.
Where Pulsy is going
Directional, not a commitment with dates. Priorities shift with what users actually ask for.
- More check types beyond HTTP — TCP and DNS are the most-requested.
- Multi-region checking for self-hosted deployments running more than one instance.
- A richer public API and webhook payload schema.
- More notification channels, driven by what people open issues about.
- Continued localization work, with right-to-left support treated as a first-class requirement rather than an afterthought.
Have something you need? Open an issue — that is genuinely how this list gets reordered. GitHub issues
Frequently asked questions
- Can I use Pulsy commercially?
- Yes. The AGPL places no restriction on commercial use. Monitor your company's production systems, run it for your team, charge your own customers for a service that depends on it — all permitted.
- If I modify Pulsy, do I have to publish my changes?
- Only if you distribute the modified version, or run it as a network service that other people use. Private internal changes you never hand to anyone else carry no publication obligation.
- Why AGPL rather than MIT or Apache?
- Because Pulsy is the kind of software people run as a service. A permissive licence would let a provider build a closed product on it and give nothing back; the AGPL's network clause closes that. It is a stricter licence, and that is the trade being made deliberately.
- Is the pulsy.org Cloud service running this exact code?
- Yes. Cloud enables the payments flag and adds plan enforcement on top; the monitoring engine, the scheduler, the notification dispatch, and the UI are the code in the repository.
- Who maintains Pulsy?
- It is developed in the open on GitHub, and Pulsy Cloud revenue is what funds the time spent on it. Issues, discussions, and pull requests are all public.
Start monitoring in minutes
Fully-managed uptime monitoring — every channel, status pages, and TLS-expiry alerts included. Start free.