# AppDeploy Security

Canonical URL: https://appdeploy.ai/security
Last modified: November 9, 2026

## Overview
AppDeploy is designed to isolate apps, scope data access, and protect user data with multiple controls working together: tenant boundaries, short-lived credentials, sandboxed execution, encryption, and operational safeguards.

## Trust overview
- **Data processing agreement:** [Available](https://appdeploy.ai/dpa)
- **Subprocessors:** [Public list available](https://appdeploy.ai/subprocessors)
- **Primary data storage and runtime region:** us-east-1 (N. Virginia)
- **CDN / edge delivery:** May use global edge locations for content delivery.
- **DDoS protection:** AppDeploy hosting includes automatic protection against common network and transport layer distributed denial-of-service (DDoS) attacks. These attacks try to overload network capacity or connections.
- **Public app links:** Deployment URLs are random and non-sequential, but anyone with the link can access the app unless the app adds authentication and authorization.
- **Log and backup retention:** Build logs up to 30 days, security and access logs up to 90 days, backups up to 30 days after deletion.
- **Data restrictions:** Do not submit secrets or payment card data in builder inputs, source files or logs; use the approved secrets flow for credentials. Runtime ID processing requires an active Plus subscription, except for the Terms' limited 30-day transition, and is subject to the DPA. No HIPAA workloads without a written BAA.
- **Operational staff access:** Limited to authorized personnel under least-privilege controls for support, security, and reliability.
- **Security reporting:** security@appdeploy.ai

## Shared responsibility
AppDeploy secures the platform and hosting environment. You remain responsible for app-level authentication, authorization, user permissions, and deciding what data your app collects or stores.

## Platform protections
- Infrastructure security and hosted runtime controls.
- App isolation, scoped access, and sandboxed execution.
- Credential handling, encryption, monitoring, and recovery practices.

## Security at a glance
- **Tenant isolation:** Each app is kept in its own scope so another AppDeploy app cannot read your app's files, database records, or internal messages through normal platform paths.
- **Short-lived credentials:** Tenant-scoped access uses temporary credentials generated for a specific app and operation, reducing reuse risk if a credential is exposed.
- **Sandboxed execution:** Backend code runs in a constrained sandbox with limited filesystem and runtime access, helping contain buggy or malicious code within its app boundary.
- **Policy-enforced boundaries:** Separation is enforced at the infrastructure level as well as in application logic, so storage and shared data access remain tenant-scoped by policy.
- **Secrets handling guidance:** Keep secrets, API keys, payment card data, real government ID numbers and other restricted data out of builder prompts and project files. Permitted ID-number processing belongs in the running app.
- **Encryption and operations:** AppDeploy uses TLS in transit, encryption at rest where supported, least-privilege internal access, and operational monitoring and recovery practices.

## Sensitive and unsupported data
Keep secrets, payment card data, real government ID numbers and other restricted data out of builder prompts, project files and messages. AppDeploy does not support HIPAA workloads and should not be used for PHI or ePHI unless agreed separately in writing under a BAA.

## Runtime ID processing and data minimisation
The Terms permit lawful runtime processing of government-issued personal identification numbers with an active Plus subscription or during the Terms' limited 30-day transition under the standard DPA, including transient validation and hashing. The transition is for existing ID-processing apps after Plus first becomes past due or ends; restore Plus or stop collection and delete stored numbers by the deadline, subject to normal backup retention. Cancellation does not restart the period, and it grants no credits or other paid benefits. Protect access and retain raw numbers only when necessary. For matching, prefer HMAC with a protected backend secret over an unkeyed hash of a predictable identifier, and use masked display references. Keep raw identifiers out of builder inputs, source files and diagnostic artifacts; use synthetic test data. Do not collect identification-number authentication bundles for third-party services. AppDeploy will not use visitor personal data or derived identifiers for training or independent partner use. Other data restrictions still apply.

Check that request bodies and error paths do not expose raw identifiers. See the [Terms](https://appdeploy.ai/terms#government-identification-numbers) and [DPA](https://appdeploy.ai/dpa) for the applicable requirements.

## Retention
Build logs are retained for up to 30 days, security and access logs for up to 90 days, and backups for up to 30 days after deletion on a rolling basis for disaster recovery.

## Public app links
Deployment URLs are random and non-sequential, but anyone with the link can access the app unless the app adds authentication and authorization, which are built-in capabilities in the AppDeploy SDK.

## Staff access
Operational access is intended to be limited to authorized personnel under least-privilege controls for support, security, and reliability purposes. AppDeploy's platform controls are designed to keep tenant data scoped, but internal operational access is not the same thing as end-user access inside your app.

## Subprocessors
- **Amazon Web Services (AWS):** Hosting, storage, runtime execution, logging, and CDN delivery. Primary region: us-east-1; CDN delivery may use global edge locations.
- **Google LLC (Firebase Authentication):** Optional sign-in and identity verification. Region: United States.
- **Astrodon Corporation (Loops):** Authentication emails for deployed-app end users. Locations: see https://loops.so/subprocessors.

Authoritative list: [Subprocessors](https://appdeploy.ai/subprocessors)

## Related trust resources
- [Privacy Policy](https://appdeploy.ai/privacy) - how AppDeploy handles personal data, logs, retention, and data rights.
- [DPA](https://appdeploy.ai/dpa) - data processing terms, responsibilities, and transfer safeguards.
- [Subprocessors](https://appdeploy.ai/subprocessors) - the infrastructure and service providers used to operate the platform.
- [Security blog post](https://appdeploy.ai/blog/appdeploy-security) - a longer narrative version of the platform security model and FAQ.
- [Vulnerability Disclosure Program](https://appdeploy.ai/vulnerability-disclosure-program) - scope, proof requirements, and research rules for high-impact security reports.

## Security FAQ
### What are AppDeploy's core security controls?
AppDeploy uses layered controls including tenant isolation, short-lived credentials, sandboxed execution, encryption in transit, encrypted storage where supported, and infrastructure-level policy enforcement.
AppDeploy hosting includes automatic protection against common network and transport layer distributed denial-of-service (DDoS) attacks. These attacks try to overload network capacity or connections.
For more detail, see [How AppDeploy protects app and user data](/blog/appdeploy-security).

### Can I deploy sensitive or regulated data?
Restricted data must stay out of builder inputs, source files and diagnostic artifacts. The [Terms](/terms#government-identification-numbers) permit lawful runtime processing of personal identification numbers, including transient validation and hashing, under the [DPA](/dpa) with an active Plus subscription or during the Terms' limited 30-day transition for existing ID-processing apps; stop collection and delete stored numbers by the deadline unless Plus is restored. AppDeploy will not use visitor personal data or derived identifiers for training or independent partner use on Free, Lite, and Plus. Protect access, retain raw numbers only where necessary, prefer a keyed hash for matching, and use synthetic test data. Do not collect identification-number authentication bundles for third-party services. Other restrictions, including those for health/disability and biometric information, still apply; special-category data requires the DPA's written agreement, and HIPAA workloads require a written BAA.

### How long are logs and backups retained?
Build logs are retained for up to 30 days, security and access logs for up to 90 days, and backups for up to 30 days after deletion on a rolling basis for disaster recovery.

### Are deployed app links private?
No. Deployment URLs are random and non-sequential, but anyone with the link can access the app unless the app adds authentication and authorization, which are built-in capabilities in the AppDeploy SDK.

### What stops one AppDeploy app from reading another app's data?
AppDeploy combines tenant-scoped data paths with infrastructure-level policy enforcement. In practice, storage access, shared database access, and internal service paths are designed to stay within the current app's scope.

### Can AppDeploy staff access my app data?
Operational access is intended to be limited to authorized personnel under least-privilege controls for support, security, and reliability purposes.
AppDeploy's platform controls are designed to keep tenant data scoped, but internal operational access is not the same thing as end-user access inside your app.

Full FAQ: [FAQ](https://appdeploy.ai/faq)

## Reporting
Report security issues to [security@appdeploy.ai](mailto:security@appdeploy.ai?subject=Responsible%20disclosure&body=Vulnerability%20title%3A%0D%0A%0D%0AAffected%20AppDeploy%20area%20or%20endpoint%3A%0D%0A%0D%0AVulnerability%20category%3A%0D%0A%0D%0AStep-by-step%20reproduction%20instructions%3A%0D%0A%0D%0APoC%20or%20proof-of-compromise%20evidence%3A%0D%0A%0D%0AImpact%20assessment%3A%0D%0A%0D%0ASuggested%20remediation%2C%20if%20available%3A). For responsible disclosure, include the affected app or URL, reproduction steps, expected impact, and any relevant logs or screenshots.