Legal

Security

How Reshot scopes capture runtime, delivery, access control, and rollout-ready security information.

Effective: May 10, 2026

Summary

Reshot is designed around a clear security boundary: customers define what to capture, run capture workflows in environments they control, and decide what to store or publish. Reshot provides hosted workflow, storage, comparison, approval, and delivery infrastructure protected by access controls, encryption, monitoring, and vendor safeguards.

This page is a security overview, not a warranty or SLA. Contractual security commitments are in the Terms of Service, Privacy Policy, and DPA.

1. Product boundary

Reshot automates documentation screenshots and related visual assets. A typical workflow includes:

defining capture scenarios;
running the CLI or workflow against an application environment;
uploading approved screenshots, baselines, diffs, or metadata;
reviewing visual changes;
publishing approved assets through stable URLs or exports; and
embedding those assets in documentation or internal workflows.

Customers control the application environment, scenario configuration, credentials, test data, redaction, and publication decisions.

2. Capture runtime boundary

The capture runtime may execute locally, in CI/CD, or in another customer-controlled environment. This design allows customers to keep production credentials, internal apps, and test fixtures within their own operational boundary where appropriate.

Reshot does not require direct production application access unless you configure it that way. You should avoid capturing live personal data, secrets, tokens, or regulated information. Use test environments, fixture data, redaction, or bring-your-own-storage when needed.

3. Customer Content and screenshots

Screenshots may contain confidential information or personal data. Reshot treats uploaded screenshots and related metadata as Customer Content under the Terms and, where personal data is involved, as Customer Personal Data under the DPA.

Customers are responsible for:

deciding what applications, pages, and states to capture;
excluding or redacting sensitive data;
securing CLI/API tokens and CI/CD secrets;
reviewing screenshots before publication;
configuring workspace access controls; and
removing or unpublishing assets that should no longer be available.

4. Access controls

Reshot workspaces use authenticated access and role-based authorization. Workspace owners and administrators control member access, roles, project access, publishing settings, integrations, and billing.

Enterprise or order-form customers may request additional controls such as SSO/SAML, custom retention, audit logs, bring-your-own-storage, private support channels, or security questionnaires, where available.

5. Encryption

Reshot uses TLS 1.2 or higher for data in transit. Data at rest is encrypted or protected using storage-layer encryption provided by our infrastructure providers, such as AES-256 or equivalent controls where supported.

Customer-controlled environments, CI/CD systems, external documentation sites, and customer-selected storage destinations are outside Reshot’s direct control and should be secured by the customer.

6. Infrastructure and vendors

Reshot uses third-party infrastructure and service providers for hosting, storage, CDN, email, support, analytics, error monitoring, payments, caching, and security. Current providers are listed at reshot.dev/legal/subprocessors.

We rely on written agreements, data processing terms, security controls, and vendor review appropriate to the provider’s role and risk.

7. Logging and monitoring

We use operational logs, error monitoring, analytics, and security telemetry to maintain reliability, debug issues, investigate abuse, and respond to incidents. Logs are access-restricted and retained for limited periods based on operational, legal, and security needs.

Customers should avoid sending secrets or unnecessary personal data in project names, scenario names, webhook URLs, error messages, support tickets, or CLI arguments.

8. API keys and tokens

API keys, CLI tokens, and integration credentials must be protected like passwords. Do not commit them to public repositories, embed them in client-side code, share them in support chats, or expose them in screenshots.

If a token is compromised, revoke or rotate it immediately and notify us if you believe Reshot systems are affected.

9. Published assets

Stable asset URLs are useful for documentation embeds, but they also create publication risk. Unless your plan or configuration restricts access, anyone with a published asset URL may be able to view the asset.

Before publishing, verify that the asset does not contain secrets, sensitive personal data, confidential customer data, or unreleased information. Removing an asset from Reshot may not remove cached, downloaded, indexed, or third-party embedded copies.

10. Incident response

We maintain an incident response process covering detection, triage, containment, investigation, remediation, notification, and post-incident review. If a security incident affects Customer Personal Data, we notify affected customers under the DPA and applicable law.

11. Vulnerability reporting

Report suspected vulnerabilities to security@reshot.dev.

Do not access other customers’ data, degrade the Service, run destructive tests, install persistence, exfiltrate data, or publicly disclose a vulnerability before we have had a reasonable opportunity to investigate and remediate.

13. Contact

Security reports: security@reshot.dev Privacy and DPA inquiries: privacy@reshot.dev General support: support@reshot.dev