This page is the plain-English answer to the question every IT security reviewer asks: “What happens to the stuff we upload to your service, and for how long do you keep it?”
For the legal version of the same answer, see our Privacy Policy and Terms of Service. For the technical controls behind these commitments, see the main Security & Trust Center.
The short version
- Uploaded installers are processed in isolated, ephemeral environments and stored only as long as we need them to package, deploy, and verify your app.
- We never train AI models on your installers, tenant data, deployment history, or audit logs. We never share your data across customer organizations.
- You can delete an organization, a package, or your account at any time. When you do, we delete the underlying data — including installer artifacts — on a defined schedule.
What we store
Installer files you upload
When you upload a Windows .exe / .msi or a macOS .pkg, we store the binary on a managed object-storage backend (Vercel Blob, US region). It’s held there long enough to:
- analyze and detect silent-install switches,
- generate the IntuneWin or Jamf-ready package,
- let you preview, download, or deploy the package, and
- let you re-deploy the same version without re-uploading.
Installer binaries are not executed inside Snap2Deploy. They are analyzed (read-only) using metadata extraction tools and packaged into the format Intune or Jamf expects. The actual installation runs on the customer’s endpoint, not on our infrastructure.
We do send the SHA-256 hash of every uploaded installer to VirusTotal’s public API for reputation scanning — this is hash-only, the file bytes never leave our infrastructure. The result (clean / flagged / unknown to VT) is stored on the package row and shown to you on the package detail and audit pages. See /subprocessors for the full VirusTotal entry.
Tenant credentials
When you connect Microsoft Intune (Entra ID app secret) or Jamf Pro (API credentials), we store those secrets encrypted at rest with AES-256-GCM, using a key managed by our application. The encryption key is rotated periodically and is separate from the database password. Plaintext secrets are never logged.
Package metadata
For every package we generate, we keep its identifier, name, version, size, SHA-256 hash, install/uninstall commands, detection rules, and the deployment events tied to it (when it was uploaded, when it was deployed, who deployed it). This metadata stays as long as the parent package exists.
Auto-Pilot patch events
For monitored apps, we keep a record of each scan: timestamp, currently-deployed version, latest-available version, action taken (notify / auto-deploy / no-op), and outcome. Retained for 12 months rolling.
Account & user data
Per user: name, work email, hashed password (bcrypt), role in your organization, last-active timestamp. Per organization: name, plan, Stripe customer ID, member list, audit log. We never store plaintext passwords.
Server logs
Standard request logs (timestamp, IP address, user agent, request path, response code, error trace if any) are retained by our hosting provider for up to 30 days for debugging and abuse detection. Logs do not include request bodies, so installer binaries and credentials never appear in logs.
What we do not do
- We do not train AI models on your data. Not on installers, not on tenant metadata, not on deployment history, not on logs, not on audit events. Period.
- We do not share data across customer organizations. Every record is scoped to one organization at the database level. A user from organization A cannot see organization B’s data through any path.
- We do not sell your data. We have no advertising partners, no data brokers, no “data products.”
- We do not run installers as part of our service. Snap2Deploy generates packages; the actual installation happens on your endpoints, managed by your Intune or Jamf tenant.
- We do not retain installer files indefinitely. When you delete a package, the underlying installer is deleted from object storage.
Retention & deletion
When you delete a package
Deleting a package removes the package metadata and triggers a best-effort delete of the associated installer artifact from object storage. The deletion completes within minutes under normal conditions and within 24 hours in the unlikely case of a backend failure.
When you delete a user
Removing a member from your organization revokes their access immediately. Their personal record (name, email, hashed password) is retained while the organization exists, in case they are re-invited. If the user account is permanently deleted at the user’s request, their personal data is purged within 30 days.
When you delete (or close) an organization
Deletion of an organization is owner-only and irreversible. We delete:
- MDM credentials (Intune / Jamf): immediately, on the same request.
- Package metadata, deployment records, Auto-Pilot monitors and events, audit logs: within 30 days.
- Installer artifacts in object storage: within 30 days.
- Encrypted database backups containing your data: within 30 days of expiring out of the rolling backup window (Neon’s point-in-time recovery window).
After 30 days, the only residue of a deleted organization is in compressed, encrypted off-site backups, which themselves expire within the configured backup retention window.
Inactive accounts
We do not currently auto-delete inactive Free-tier accounts. If that changes we will update this page and notify you in advance.
Where your data lives
Snap2Deploy serves customers globally but our infrastructure is currently US-region only:
- Application: Vercel, US region.
- Database: Neon Postgres, US region.
- Installer object storage: Vercel Blob, US region.
- Email delivery: Resend, US region.
If your organization requires EU data residency before purchase, email security@snap2deploy.com — this is on our roadmap and we’d like to know your timeline.
Your rights
Owners and admins can export their organization’s data at any time via the Settings page. To request a full data export or deletion of personal information, email privacy@snap2deploy.com. We respond within 30 days, in line with our Privacy Policy.
Reading what’s actually in our database
For curious or careful reviewers: the canonical data model is the Prisma schema in our application repository. The objects you upload and the metadata we generate are stored exactly as described above. If you find a discrepancy between this page and the implementation, please email security@snap2deploy.com — we treat documentation drift as a defect.