Privacy Policy

This policy applies to ProcBoss Cloud — procboss.com, the dashboard, the pboss agent, the @procbossbot Telegram bot, and any bot we operate on Discord. The controller of your data is ProcBoss, the operator of the service; the contact for every privacy matter, request, or complaint is support@procboss.dev.

The pboss CLI is open-source software you run yourself; when the CLI talks to your own machine without the cloud, that processing is yours, and this policy does not cover it. It covers what reaches our servers — and everything below says exactly what that is.

Account identity, through OAuth only. Signing in with GitHub or Google shares your profile name, email address and account handle with us. The permissions we request are read-only — read:user user:email on GitHub, openid email profile on Google. When you connect a git host for deploys we store an OAuth token for it, encrypted at rest with a per-deployment key.

Fleet telemetry, from servers you connect. When you run pboss cloud connect on a machine, the agent you installed reports that server's hostname, OS and architecture, CPU and memory metrics, process names, states and uptime, restart and crash events, deployment results, and the log lines you explicitly request through the dashboard or the bots. Everything in this category is generated by the agent you control, on the servers you chose to link — nothing is collected from machines you never connected.

Notification channels you link. Pairing a Telegram chat or a Discord channel or webhook stores the channel identifier and, for bots, your platform user id — enough to address messages to you, and no more. Unlinking deletes it.

Billing records. If you buy a paid plan: the invoice, the amounts, the plan, and the billing email. Payment credentials are handled by the payment provider, not stored by us.

Support tickets and operational logs. Messages you send to support, and standard request logs (time, route, status code, IP address, user agent) retained briefly for security and abuse investigation.

No passwords — sign-in is OAuth-only, so there is no password database to breach. No source code or repository contents — the OAuth scopes above do not grant them. No SSH keys or shell access to your machines — the pboss agent connects outward to us over an authenticated, signed channel; we never dial in. No advertising identifiers, no cross-site trackers, no analytics cookies, no selling of anything to anyone.

To provide the service: showing your dashboard, evaluating your alerts, running your deploys, delivering the notifications you asked for, and keeping your quota accounting straight. To bill and to keep the billing records tax law expects.

To keep the service and your account safe: rate limiting, abuse detection, investigating incidents, and keeping the operational logs that answer what happened when. To answer you — support tickets exist to be read and replied to. And, in aggregate that carries no personal identity, to understand how the product is used so it can be improved. Legal bases, where GDPR-style law applies: contract performance for the running of your account, legitimate interest for security and aggregate product insight, and consent for the channels you explicitly link.

Two kinds, both first-party and functional: a session cookie (httpOnly, server-side, revocable from your account) that keeps you signed in, and short-lived OAuth state cookies (about 10 minutes) that protect the sign-in round-trip against CSRF. There are no tracking, advertising or third-party analytics cookies anywhere on the site, and nothing to opt out of.

Identity comes from GitHub and Google at sign-in. Alert delivery goes to Telegram or Discord — but only through channels you linked yourself. Infrastructure (application hosting and database hosting) is provided by commercial cloud vendors under standard data-processing terms; the minimum they receive is what running the service requires. We do not sell, rent, or share your personal data with anyone else, for advertising or any other purpose.

Those providers may process data in regions other than yours. Where that happens, transfers ride the safeguards those providers maintain (such as standard contractual clauses) plus the practical ones we add ourselves — data minimized to what the service needs, encrypted in transit, with deletion on request cutting every copy on its next backup cycle.

Fleet telemetry lives as long as the server it belongs to is connected, and for a short grace window after you unlink it — enough to restore an accidental unlink, then it is gone. Notification channel records live until unlinked. Account identity lives for the life of the account.

Operational logs are kept for up to 90 days. Support tickets are kept for up to 24 months after closure. Billing records are kept for as long as tax law requires — commonly seven years — because invoices are legal documents, not telemetry. Everything rests on encrypted backups that age out on a fixed cycle; deletion requests are honored on the live system immediately and on the backup copies on that cycle.

Deleting a server from the dashboard removes its telemetry rows and live buffers. Unlinking Telegram or Discord removes the channel. Deleting your account — ask support@procboss.dev — removes your user record, sessions, integrations and fleet data.

Where GDPR-style law applies you also have the formal rights: access (an export of what we hold), correction, deletion, portability in a machine-readable format, objection and restriction. To exercise any of them, email the address above from the address on your account; we answer within 30 days, usually much faster. If you are unhappy with the answer, you can complain to your local data protection authority — and we would rather you wrote to us first.

Sessions are server-side and httpOnly. The agent gateway is mutually-authenticated and every command is signed with a per-installation secret. Telegram updates are accepted only with a valid webhook signature; Discord interactions only with a valid Ed25519 signature. Deploy tokens and connection secrets are encrypted at rest. OAuth sign-in uses a per-request CSRF state token, and sign-in only starts from origins this deployment operates (a forged host header cannot redirect the flow at a foreign domain). If a breach ever materially affects your data, we will tell you promptly and plainly.

The service is not directed to children, and we do not knowingly collect data from anyone under 16 (or the higher age your jurisdiction sets). If you believe a minor created an account, write to us — the account and its data will be removed.

When the service changes in a way that changes what data it handles, this page changes with it. Material changes are announced in the service or by email before they take effect; the “last updated” line above is the audit trail, and the previous version is available on request.