Usage this monthBilled to your own provider account
9:41
Tokens encrypted at rest Official APIs only
Follow your data through AeroReply
Pick something you trust us with and see exactly where it goes and how it’s protected.
1Your browser
2HTTPS · TLS
3AeroReply API
4AES-256-GCM
Stored encrypted
Encryption in transit and at rest
Every request to AeroReply is served over HTTPS, with TLS certificates issued and renewed automatically at our edge proxy. The sensitive values we hold on your behalf are encrypted at rest with AES-256-GCM using a fresh initialisation vector per value and an authentication tag on every record — that covers OAuth access and refresh tokens for your connected social accounts, platform client secrets, stored provider credentials, and webhook destinations. Encryption keys are supplied to the application through the environment and are never written into the database alongside the data they protect.
Authentication and access control
Passwords are hashed with bcrypt at cost factor 12 and are never stored, logged, or recoverable in plain text. A signed-in session uses a short-lived access token (15 minutes by default) paired with a long-lived refresh token that exists in our database only as a SHA-256 hash; every refresh rotates that token, and replaying an already-rotated token is treated as theft and revokes every live session for that account. Sign-in endpoints, password resets, and public endpoints are rate limited per IP. Inside a workspace, access is governed by roles resolving to a granular permission catalogue, and every workspace-scoped endpoint verifies your membership and the specific permission before it reads or writes anything. Public API keys are generated with cryptographically random bytes, shown to you exactly once, and stored only as a SHA-256 hash next to a truncated display prefix — we genuinely cannot recover a lost key, only rotate or revoke it — and each key carries an explicit read or write scope enforced on every route.
Infrastructure and hosting
AeroReply runs as a containerised stack — web application, API, background workers, PostgreSQL, and Redis — behind a single reverse proxy that terminates TLS. The datastores publish no ports to the public internet; the proxy is the only component accepting inbound traffic. Uploaded media lives in object storage and is written through short-lived presigned uploads rather than any broadly-writable bucket. At the API edge we apply standard HTTP hardening: security headers, an explicit CORS origin allowlist rather than a wildcard, and request body size limits. Any URL you supply that we then call — a webhook destination, an imported feed — is validated against private, loopback, and reserved address ranges first, so the platform cannot be used to reach internal networks.
Backups and disaster recovery
The production database is dumped on an automated nightly schedule and the archive is shipped to object storage held separately from the application host. Redis runs with append-only persistence so queued and in-flight jobs — scheduled posts, renders, deliveries — survive a restart rather than being silently dropped. Destructive actions in the product are soft deletes by design: deleted records are marked and filtered out of every read path rather than being immediately erased, which means an accidental deletion is recoverable. We do not publish a contractual recovery time or recovery point objective, and we would rather say so than quote a number we have not tested. If your organisation needs specific recovery commitments in writing, contact us before you buy.
Sub-processors
We use a small number of third parties to run the service, and we do not sell, rent, or trade your data to anyone. Payments and subscription billing are handled by Stripe, which processes card details directly — card numbers never reach our servers. Uploaded media is stored in Amazon S3. Transactional email is delivered through our email provider. AI features call the model provider configured for your workspace, and your content is sent to that provider only at the moment you invoke an AI feature. Publishing, messaging, and analytics features exchange data with the social platforms you choose to connect, under those platforms’ own terms. If you need the current list of sub-processors in a form you can attach to a vendor review, email us and we will send it.
Responsible disclosure
If you believe you have found a vulnerability, please report it to security@aeroreply.com before disclosing it anywhere else. Include enough detail for us to reproduce the issue — a proof of concept, affected endpoint, and impact. We will acknowledge every good-faith report, keep you updated while we work on it, and credit you if you would like us to. In return we ask that you do not run automated scanners against production, do not degrade the service for other customers, and do not access, modify, or retain data belonging to anyone but yourself. We will not pursue legal action against researchers acting in good faith within those limits.
Straight answers from the builders
Compliance posture
Specific answers instead of badges
We are not currently certified against SOC 2, ISO 27001, or any comparable framework, and we will not imply otherwise. The practices above are how the system is built today, and we are happy to walk through any of them. You can delete your workspace at any time, and disconnecting a social account wipes the tokens we stored for it.
