An over-the-air update service can change what runs inside your app, on every device, without review. That is the whole value and it is also the whole risk. This page is what we do about it, and what we do not do yet.
Turn on code signing and upload your own key pair. Every release is signed at publish time with RS256, and the device verifies the signature against your public key before the update is applied. A bundle that has been altered in transit, at the CDN, or anywhere else does not run. We never hold your private key.
Every release and every file inside it carries a SHA-256 content hash. The client checks what it downloaded against what was published, so a truncated or corrupted download fails closed rather than installing a partial bundle.
Bundles are served from the CDN through signed URLs that carry a token and an expiry, valid for one hour. A URL lifted from a log or a proxy stops working. Delivery is restricted by country at the edge, and all traffic is HTTPS.
DeployPulse watches the error rate across your install base on every release and reverts to the last stable one when it crosses a threshold you set, checked every five minutes, then emails you and fires your webhooks. Availability is part of security, and this is the control that limits the blast radius of a bad push.
Access keys can be issued read-only or full, and restricted to named apps. A key that only needs to read deployment history cannot publish a release, and a key for one app cannot reach another. Keys can be given an expiry and revoked individually.
Access keys are hashed before storage and looked up by hash. A database dump does not yield a usable key, and we cannot show you an existing key again after it is created, only replace it.
Dashboard session cookies are encrypted with AES-256-GCM, which is authenticated, so a tampered cookie is rejected rather than decoded. Sessions slide with use and have a hard lifetime, and you can sign out every session at once from Settings.
Apps can be owned by an organization rather than a person, with per-member roles, so access survives someone leaving and does not depend on one individual's account. Every permission decision is enforced server-side.
Authentication, one-time codes, releases and the update-check path all carry independent rate limits, shared across our servers rather than per process. Repeated failed authentication from an address is locked out.
There are no passwords on DeployPulse accounts, because there is no password field at all. You sign in with GitHub, GitLab or Google, or with a one-time link sent to your email. Nothing to reuse from another breach, nothing to phish, and nothing for us to lose.
Connecting a second sign-in method to an existing account requires a verified email address on both sides, so an unverified account elsewhere cannot be used to claim yours.
HSTS with a one-year max-age including subdomains, a content security policy on the dashboard, and nosniff, X-Frame-Options: DENY and a strict referrer policy on every response.
The API reaches Postgres over its own database role, restricted to our servers' static addresses. The hosted database's public data and GraphQL APIs are switched off entirely, so the only path to your data is through our application.
Every third party that touches customer data is listed publicly, with what it does and where it runs. See the subprocessor list.
The SDK sends a client identifier, the app and deployment it is asking about, its current version, and whether an update succeeded. That is what drives adoption analytics, error-rate rollback and billing. We do not receive your users' personal data, and we never see your source code, only the bundle you publish.
Email support@deploypulse.io with the details, or use the contact form and pick Security. Please do not open a public issue. We will acknowledge your report, tell you what we find, and credit you if you would like to be credited.
Last reviewed:
Features
Pricing
FAQs
Docs
Contact