Security

snoozestack runs in Amazon Web Services, in a single region — US West (Oregon), us-west-2. Your project data, databases, files, backups, and logs are stored in that region. A small amount of edge configuration (the CDN's TLS certificates and web-application-firewall rules) lives in us-east-1 because AWS requires CloudFront to manage those there; no customer content is stored in it.

Databases. A control-plane PostgreSQL database holds accounts, projects, and platform metadata. Each project also gets its own isolated data: a per-project PostgreSQL database and a per-project runtime store (SQLite files — your project's application database, its end-user identity, and its analytics), continuously replicated to that project's own private object-storage bucket.

Files and object storage. Each project has its own private S3 bucket for uploaded files, published site/function/runtime versions, database replicas, and nightly backups — each kept on a separate key prefix.

Queues, logs, secrets. Project queues run on Amazon SQS. Container and request logs go to Amazon CloudWatch. Platform-level secrets are stored in AWS Systems Manager Parameter Store as encrypted (SecureString) values.

Data is region-bound: it is not replicated to other AWS regions. It is not processed by third-party subprocessors beyond those listed below.

In transit. Public traffic to the console, project APIs, and custom domains is served over HTTPS/TLS, terminated at the CDN (Amazon CloudFront). Connections to the PostgreSQL database require TLS — the server refuses an unencrypted connection. One leg is not encrypted and we describe it plainly: between CloudFront and our load balancer, traffic travels over HTTP inside our private AWS network (VPC), never across the public internet.

At rest. The RDS PostgreSQL database is encrypted at rest, and its automated backups inherit that encryption. Project object-storage buckets and the instances' disks use AWS-managed encryption. Key management is handled by AWS (KMS / S3-managed keys); snoozestack does not operate its own hardware security module.

Multi-tenant isolation is enforced by giving each project its own resources rather than sharing one and filtering: a project has its own database, own object-storage bucket, own queues, own runtime container, and its own credentials. Within the shared object-storage bucket, uploads, published versions, database replicas, and backups are separated onto distinct key prefixes, and a custom domain's access is restricted by bucket policy so it can only read that project's published site — never its uploads, replicas, or backups.

The compute hosts that run project containers are never reachable from the internet: they accept connections only from the platform's own router, inside the private network, over a per-project allocated port. All requests to a project reach it through the platform, which routes by hostname. Instance metadata is locked to IMDSv2.

Web application firewall. Every public CloudFront distribution is fronted by AWS WAF. The console and admin surfaces use AWS's managed strict rule set; the project data plane uses the same managed protections with common attack categories (cross-site scripting, SQL injection, known-bad inputs) set to block.

Network segmentation. Hosts run in a private VPC with security groups scoped so that the agent that controls containers and the tenant container ports are reachable only from the platform's own hosts, never from a public range. The database is not reachable from the public internet: its security group accepts connections only from the platform's own compute, and every connection still requires TLS and credentials.

Least-privilege access. Cloud permissions are granted through IAM roles scoped to snoozestack-owned resources. Continuous-integration deploys authenticate to AWS through short-lived GitHub OIDC credentials rather than long-lived keys for the deploy path.

Console and admin access. Access to the operator console and the admin console is authenticated with server-side session secrets held in Parameter Store, never shipped to a browser or a tenant container.

Project API keys. Each project has a public (anon) key and a secret (service-role) key. The service-role key is privileged and must stay server-side. Keys are stored in the control plane and can be viewed by the project owner in the console; end-user session tokens for a project are short-lived and signed by that project's own signing key, held in the project's runtime — so a session can be revoked immediately rather than waiting out its lifetime.

Project secrets. Secrets you set for your project (third-party credentials, signing keys, provider client secrets) are stored in the control plane and injected into your runtime at start. Management APIs report only whether a secret is set, never its value.

The control and per-project PostgreSQL databases have 7-day automated backups (encrypted). Each project's database is additionally dumped nightly to that project's own bucket, and the project runtime's SQLite store is continuously replicated to object storage, so a project can be restored onto another host.

In the interest of accuracy: the database runs in a single availability zone today, and we do not currently advertise a formal recovery-time objective or disaster-recovery attestation. Improving database resilience is tracked work, not a claim we make here.

Container and request logs and platform metrics are collected in CloudWatch and retained for 30 days. Operational status is published at status.snoozestack.com, on its own independent infrastructure so it can report an outage that affects the rest of the platform. We notify affected customers of security incidents and material privacy events by email to the account contact and, where appropriate, through the status page.

What we collect is described in the Privacy Policy: account information (email, hashed password), the project data you create so we can run it for you, and usage/log data for operating, securing, and debugging the Service. Data your own project stores about your own end users is yours — you are its controller, and your own policy governs it.

Retention. Operational logs and metrics are retained for 30 days. Database backups are retained for 7 days. Account and project data persists while your account is active.

Deletion. Deleting a project removes its databases, its bucket, its queues, and its running containers. An end user of your application can delete their own account and its identity data through the identity SDK. When you close your account, we remove your account and project data; copies in short-lived backups age out on the backup retention window above rather than being erased individually.

Export. You have direct programmatic access to your own project data at any time — the database, files, and configuration are yours to read and export through the CLI, SDKs, and management API.

snoozestack secures the platform: the infrastructure, network, encryption, isolation between projects, and the controls above. You secure what you build on it: your application code and dependencies, how you store and protect your project's API keys and secrets, the access control and authorization rules inside your own functions, and the data you and your end users choose to store. Keeping the service-role key server-side, and reviewing your own function authorization, are yours to own.

We use a small number of third parties to run the Service:

Amazon Web Services — all compute, databases, object storage, queues, logging, CDN, and email delivery (Amazon SES). Stripe — payment processing for paid plans (Stripe receives billing details, not your project data). Our marketing website uses privacy-respecting analytics to understand traffic. See the Privacy Policy for how each category of data is used.

We do not hold, and do not claim, SOC 2, ISO 27001, HIPAA, or PCI certification, and we do not currently run a formal third-party penetration test or a paid bug-bounty program. When any of that changes, it will appear here with its scope and date — not before.

If you believe you have found a security issue, email support@snoozestack.com with the details and steps to reproduce. Please test only against your own account and projects, avoid accessing or modifying other customers' data, and give us a reasonable chance to respond before disclosing publicly. We investigate reports made in good faith and will not pursue action against researchers who follow this guidance.

Security or privacy questions? Contact support@snoozestack.com.