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 and deletes their user record (name, email, hashed password, MFA enrollment) immediately. Admins and members can also delete their own account at any time from Profile → Delete account. Packages and deployments the user created belong to the organization and are kept; audit log entries they generated remain part of the organization’s audit trail until that trail’s retention period expires.
When you close an organization
The organization owner can close the organization from Settings → General → Close organization, after re-entering their password (and MFA code, if enabled). Closing starts a 7-day grace period: deployments and Auto-Pilot are paused, the subscription stops renewing, every member is notified by email, and the owner can cancel at any time. When the grace period ends we permanently delete, in a single operation:
- Every user account in the organization, pending invitations, and stored MDM credentials (Intune / Jamf).
- Package metadata, deployment records, Auto-Pilot monitors and events, and audit logs.
- Installer artifacts in object storage.
- The Stripe subscription, which is canceled. Invoices and payment records held by Stripe are retained for tax and accounting purposes.
Residual copies remain only in encrypted database backups, which expire within 30 days as they roll out of Neon’s point-in-time recovery window. We keep a single anonymized record that the deletion took place (organization id, date, and record counts, with no names or email addresses). Apps you already deployed to Intune or Jamf are in your MDM tenant and are not affected.
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.