Security

Every sandbox, app, and managed database runs inside its own Firecracker microVMwith a dedicated Linux kernel, on top of hardware virtualization (KVM). Tenants do not share a kernel. This is a stronger boundary than container runtimes, which isolate processes with namespaces and cgroups against a shared host kernel — a single kernel vulnerability there can cross tenants.

Firecracker is a minimal virtual machine monitor built for multi-tenant workloads. It exposes a deliberately small device model (no BIOS, no PCI, no USB), which keeps the host-facing attack surface far smaller than a general-purpose hypervisor.

Each microVM is additionally confined on the host: it runs as an unprivileged process under a seccomp filter that restricts it to the syscalls it needs, inside its own filesystem and network context.

Each sandbox is placed in its own Linux network namespace with a dedicated virtual interface and its own private subnet. Sandboxes do not share a layer-2 network and cannot address one another directly; egress is translated at the host, and teardown removes the namespace and its rules atomically.

Public preview URLs for sandboxes and apps are served over TLS. A sandbox preview URL is reachable by anyone holding the URL for the lifetime of that sandbox — the identifier is the credential. Do not expose sensitive data on a preview URL; put anything confidential behind your own application-level authentication.

In transit. Traffic to our API, dashboard, app URLs, and managed PostgreSQL endpoints is encrypted with TLS. Managed database connections require TLS.

At rest. Sandbox disks, snapshots, and stored artifacts live on cloud-provider storage with encryption at rest enabled.

Secrets. Environment variables and secrets you set on an app are encrypted with AES-256-GCM before storage, decrypted only to inject them into your workload at build and run time, and masked in API reads and build logs.

Credentials. API keys are shown once at creation. Rotate them if you suspect exposure, and never commit them to a repository. Third-party tokens we mint on your behalf (for example a GitHub App installation token used to clone a private repo) are short-lived and are not persisted.

Resources are scoped to an organization. API requests are authenticated and authorized against the owning organization, and access to a sandbox, app, database, or deployment is checked on every request rather than inferred from an identifier alone.

Within an organization, members hold an owner, admin, or member role. Treat organization membership as full access to that organization’s workloads and data.

Running attacks, spam, or unauthorized resource-intensive workloads on PandaStack is prohibited. In particular, cryptocurrency mining is not permitted on any plan. The full list of prohibited activity is in the acceptable-use section of our Terms of Service.

We monitor for abusive traffic patterns and may suspend workloads that threaten platform integrity or other customers. Report suspected abuse to hello@pandastack.ai.

The PandaStack substrate is open source under Apache-2.0. The isolation model described here is not a claim you have to take on trust — the agent that creates microVMs, configures per-sandbox networking, and manages snapshots can be read and audited at github.com/pandastack-io/pandastack-ai.

We want to be straightforward here rather than imply more than we have: PandaStack does not currently hold an audited SOC 2, ISO 27001, or HIPAA attestation. We do not claim certifications we have not completed. Our infrastructure runs on major cloud providers whose own compliance programs cover the underlying physical and platform layers.

What we do maintain today:

• GDPR / UK GDPR. We act as a processor for Customer Content under a published Data Processing Agreement with Standard Contractual Clauses for international transfers, a public subprocessor list, and deletion that actually deletes — removing a database also removes its backup archive.
• CCPA/CPRA. We do not sell personal information; consumer rights are described in our Privacy Policy.
• PCI DSS (SAQ A). All payment flows are hosted by Stripe — cardholder data never touches PandaStack systems — and we self-assess annually under SAQ A, the questionnaire defined for exactly this integration model.
• CSA CAIQ. A completed Cloud Security Alliance Consensus Assessments Initiative Questionnaire is available to customers on request via hello@pandastack.ai.
• Coordinated disclosure. A published security.txt and the reporting process in Section 8.

If your evaluation requires a security review, a countersigned DPA, or specific contractual commitments, contact hello@pandastack.ai and we will tell you plainly what we can and cannot support today.

If you believe you have found a security vulnerability, email hello@pandastack.aiwith the subject line “Security”. Please include enough detail to reproduce the issue, and give us a reasonable opportunity to investigate and remediate before public disclosure.

Please do not run testing that degrades service for other customers — no denial-of-service testing, no automated scanning that generates significant load, and no attempts to access data belonging to another organization. Testing confined to sandboxes inside your own organization is fine, subject to the acceptable-use rules above.

We do not currently operate a paid bug-bounty program, but we will acknowledge reports and credit reporters who want it.