Self-hosting & GDPR
Last updated: August 9, 2026
If you run the open-source SolidPing software on your own infrastructure, no personal data reaches us. There is no telemetry home, no licence check, no usage beacon. We supply software; we do not process your data.
That has a precise legal consequence: you are the controller, and we are not your processor. You do not need a data processing agreement with us, and none of the sub-processors on our hosted-service list touch your deployment. It also means your GDPR compliance is yours to do — this page exists to make that tractable rather than to do it for you.
This page is engineering documentation about how the software behaves. It is not legal advice, and it is not a compliance certificate. Your obligations depend on your own context — who your data subjects are, where you operate, and what you configure.
Your role, in one table
| Who | Notes | |
|---|---|---|
| Controller | You | You decide why and how personal data is processed in your deployment |
| Processor | Nobody, unless you engage one | Your hosting provider, if you use one, is likely your processor |
| Our role | Software supplier | Outside the GDPR's controller/processor chain |
| Recipients | Whatever you configure | Notification channels, identity providers, and any external endpoints you point SolidPing at |
If you host SolidPing on behalf of someone else — an internal platform team serving other legal entities, or an MSP running it for clients — then you are the processor for them, and you will need your own DPA with them. The material in our DPA and Security measures pages is a reasonable starting template.
What the software stores
To build your Article 30 record of processing activities, this is the personal data a SolidPing deployment holds. Everything below lives in your database.
| Category | Where it comes from | Notes |
|---|---|---|
| User accounts | Registration or SSO | Email, name, avatar URL, password hash, TOTP secret and recovery codes, WebAuthn credentials |
| Identity-provider links | SSO sign-in | Provider user and workspace IDs for Slack, Discord, Google, GitHub, GitLab, Microsoft, LDAP, OIDC |
| Contact details | User or admin entry | Verified phone numbers for SMS/voice escalation, notification email addresses, web-push subscriptions |
| Organisation data | Configuration | Memberships, roles, on-call schedules, escalation policies |
| Integration credentials | Configuration | OAuth tokens and API keys for the channels you connect — encrypted at the application layer when you set a master key |
| Monitoring data | Operation | Check definitions and targets, results, response times, error messages |
| Incident data | Operation | Timelines, acknowledgements, comments, resolution records |
| Status-page subscribers | Public sign-up | Email address, confirmation state, subscription scope — often people who are not your users |
| Audit and auth logs | Operation | IP address, user agent, action, timestamp |
Two of these deserve a second look when you write your record of processing: status-page subscribers are usually third parties with no other relationship to you, and check targets can be personal data when a hostname or URL path identifies an individual.
Configuring for data protection
These are the switches that matter. All of them are in the documentation.
Turn on credential encryption. Set the encryption master key so integration credentials, OAuth tokens, and TOTP secrets are encrypted at the application layer rather than sitting readable in the database. Keep the key outside the database, in your secret store.
Keep analytics off, or point them at your own instance. PostHog is inert unless you configure a project key: with none set, the server allocates no client and the dashboard never downloads the analytics chunk. If you do want product analytics, use your own PostHog project — the data goes to you, not to us.
Set retention deliberately. Result aggregation has its own retention knobs (raw, hourly, daily). Article 5(1)(e) says keep personal data no longer than necessary; the defaults are chosen for operational usefulness, not for your retention policy. Decide yours and configure it.
Choose your check regions. If you run distributed agents, an agent processes the check definitions it is given. Running an agent outside the EEA is a transfer you are responsible for. Keeping agents in-region keeps that question from arising.
Restrict registration. The registration email pattern and join policy let you decide who can create an account rather than leaving your instance open.
Turn on multi-factor authentication, and set an absolute session maximum duration rather than relying only on the sliding idle window.
Enable TLS everywhere, including between the dashboard, the API, and agents. Agents connect outbound-only, so they need no inbound exposure.
Your compliance checklist
Things only you can do:
- Write your record of processing activities (Article 30) — the table above covers the categories.
- Identify a legal basis for each purpose. Monitoring your own systems with staff accounts is usually legitimate interests; status-page email subscriptions are usually consent.
- Publish a privacy notice to your users and to status-page subscribers (Articles 13 and 14). Subscribers in particular have often had no other contact with you.
- Sign DPAs with your own processors — your cloud provider, your SMTP provider, your SMS provider.
- Document transfers outside the EEA — non-EU agent regions, and any notification channel hosted outside the EEA.
- Define retention periods and configure them.
- Have a breach procedure that can meet the 72-hour deadline in Article 33.
- Be able to answer data subject requests — see the next section.
- Assess whether a DPIA (Article 35) is needed. For ordinary infrastructure monitoring with staff accounts, usually not; if you are monitoring in a way that profiles individuals, reconsider.
- Add a cookie notice if your instance is user-facing — our Cookie Policy lists what the software stores in the browser.
Answering data subject requests on your own instance
The software gives you the mechanics:
- Access and portability — export checks and configuration through the API
(
GET /api/v1/orgs/{org}/checks/export); user and incident records are readable directly from your database. - Rectification — profile and contact fields are editable in the dashboard.
- Erasure — an organisation owner can delete an entire organisation from the dashboard (confirmed by re-typing the slug), which stops its checks, revokes its tokens, and takes down its status pages. For an individual user, delete the account and remember to check your own database backups.
- Objection — disable analytics, or the specific processing objected to.
Because it is your database, you can always go further than the UI allows. That is the point of self-hosting.
What we would like from you in return
Nothing legally. But if you find that a data-protection task is harder than it should be — a retention setting that does not exist, an export that misses something, a field you cannot purge — that is a bug worth reporting. Open an issue at github.com/fclairamb/solidping/issues. Making self-hosted compliance easy is a design goal, not an afterthought.
Related
- Security measures — the measures we apply to the hosted service; a useful reference for what to configure in your own
- Data Processing Agreement — a template of sorts, if you process on someone else's behalf
- Legal & GDPR — the full document index