Security & infrastructure
Secure by architecture, not by hope.
This page describes how Stackset products are built and operated. It is written for the technically curious user, for brand partners doing due diligence, and for investors who want to know we take custody of personal data seriously.
Core security infrastructure
Built so the database is never on the internet.
Every Stackset product ships on the same hardened platform. Clients never hold a database connection string. They talk to a narrow integration layer that authenticates, authorises and shapes every request before anything touches storage.
Integration service endpoints
Apps call purpose-built endpoints, not tables. Each endpoint validates input, checks the caller's identity and policy, and returns only the fields that screen needs. Internal database hosts have no public route, so a leaked client build or a malicious agent probing our edge finds nothing to connect to.
Single sign-on everywhere
Every internal console, dashboard and admin tool sits behind SSO with OpenID Connect and enforced multi-factor authentication. Access is role-based and reviewed; leaving the team revokes everything in one place. End users get the same care: Sign in with Apple, Google, or a one-time email code. We never see or store passwords in plain text.
Containerised applications
Each service runs in its own container with a read-only filesystem, a non-root user, pinned dependencies and an explicit egress allow-list. Workers that touch untrusted content, such as link extraction and media transcoding, are isolated from anything holding user data.
Row-level security as the last line
Even behind the gateway, the database enforces per-row policies tied to the authenticated user. A bug in one endpoint cannot read another person's private collection, message or profile.
Secrets that never sit still
Credentials are minted at deploy time, scoped to one service, rotated automatically and injected at runtime. Nothing sensitive lives in a repository, a build artefact or a developer laptop.
Encryption and auditability
TLS 1.3 in transit, AES-256 at rest, signed and immutable deploy snapshots, and structured audit logs for every privileged action. If something looks wrong we can see exactly who did what, and roll back in under a minute.
Operating principles
Seven rules we don't negotiate.
No client ever holds a database credential
Mobile and web builds contain only a public, anonymous key that unlocks nothing without a user session. Writes and sensitive reads go through integration endpoints.
SSO or nothing for internal access
Dashboards, cloud consoles, the app stores and source control sit behind SSO (OIDC) with hardware-key or app-based MFA. No shared passwords, ever.
One container, one job
Services are small, run as non-root with read-only filesystems, and can only reach the hosts on their allow-list. Compromising one does not grant the next.
Least privilege, enforced in the database
Row-level security policies bind every row to its owner. Service accounts for background workers have exactly the grants their job needs and nothing more.
Secrets are minted, not copied
Short-lived, scoped credentials are issued at deploy time and rotated automatically. Repositories, build logs and laptops never contain production secrets.
Everything is a snapshot
Every release is immutable and signed. Over-the-air updates are fingerprinted against the native binary they target. Any environment can be rolled back in under a minute.
User data
What we store and how we protect it.
Shelfie holds the data you'd expect from a social app: your profile, collections, posts, messages and a beauty profile you choose to fill in. Here's how each category is handled.
Identity
Email and password sign-in uses one-time codes, never a stored plaintext password. Sign in with Apple and Google hand us a verified identity token and nothing else.
Messages & private content
Direct messages, private collections and followers-only posts are readable only by their participants, enforced by database policy and checked again at the endpoint.
Media
Uploads are stripped of location metadata, transcoded in an isolated worker, and stored in per-user folders in object storage with scoped, expiring access.
Residency & retention
Production data is hosted in North America. You can request deletion from inside the app; we honour it across backups within 30 days.
Responsible disclosure
Found something? Tell us first.
We welcome good-faith security research on our products. Email security@stackset.io with steps to reproduce. We acknowledge within 2 business days, keep you updated, and credit researchers who want it. Please don't access other people's data, degrade the service, or publish before we've fixed the issue. A machine-readable version lives at /.well-known/security.txt.