Protect your sign-in
Add a passkey or two-factor authentication. Review your active sessions and sign out a device you no longer use.
Your accounts.
Your control.
Your business depends on the accounts you connect. Here’s how OpenPost protects them, and the controls you have.
Keep account keys private
OpenPost encrypts the credentials saved for your connected social accounts. Your password is hashed before it is stored.
Choose who has access
Use separate workspaces and member roles. Remove access for people and connected tools when they no longer need it.
How protection works.
The full details are here when you need them. Each control links to the source code behind it.
Identity, sessions, roles, and workspace access
- In OpenPost
- Hashes passwords, supports TOTP and passkeys, records revocable browser sessions, and enforces organization, workspace, scope, and action checks.
- On OpenPost Cloud
- Configures hosted identity options, preserves the break-glass administrator boundary, and responds to verified account or access incidents.
- Your part
- Users protect their sign-in methods and devices. A selected identity provider controls its own authentication and account-recovery process.
- If you self-host
- Chooses identity providers and administrator accounts, protects recovery access, reviews members and sessions, and removes access promptly.
Social credentials and application secrets
- In OpenPost
- Encrypts stored social tokens, TOTP secrets, OIDC client secrets, and saved provider-app secrets with AES-256-GCM; API-family bearer tokens are stored as hashes.
- On OpenPost Cloud
- Supplies and protects the encryption key and hosted provider credentials outside the image and repository and limits production access to the disclosed operator boundary.
- Your part
- Users revoke connections or access tokens they no longer need. Social and identity providers protect and can revoke their provider-side credentials.
- If you self-host
- Generates, stores, rotates, backs up, and restricts the encryption key, JWT secret, social app credentials, and email or storage credentials.
TLS, host, database, media, and network boundary
- In OpenPost
- Uses secure cookie attributes on HTTPS, validates trusted origins and redirect targets, and accesses database and media through configured service boundaries.
- On OpenPost Cloud
- Terminates public TLS, keeps direct host and database access inside the disclosed operator boundary, and configures the current managed data locations and providers.
- Your part
- Hosting, network, storage, and social providers secure the infrastructure and endpoints they control under their own terms.
- If you self-host
- Places OpenPost behind correctly configured TLS, restricts database and media access, patches the host and reverse proxy, and chooses where data is stored.
Human production access
- In OpenPost
- Enforces authenticated role and workspace checks. Submitting a support request does not change the user's application authorization.
- On OpenPost Cloud
- Uses the named key-only operator and sudo boundary described in the trust register. Routine application work is automated; exceptional access is limited to the stated support, recovery, security, abuse, legal, or fraud purpose.
- Your part
- Customers choose workspace members and roles. Infrastructure providers control their own privileged-access programs.
- If you self-host
- Defines who can reach the host, database, media, logs, and backups; applies least privilege; reviews keys; and records access at the level its risk requires.
Backups, restore, retention, and deletion
- In OpenPost
- Provides scoped deletion flows and durable media-cleanup jobs while protecting active publication, library, favorite, tag, template, and brand references.
- On OpenPost Cloud
- Makes the disclosed daily database and media recovery copies, prunes routine recovery history after 14 days, and performs the stated restore drill.
- Your part
- Customers resolve shared ownership and active billing blockers before account deletion and control provider-side content separately.
- If you self-host
- Chooses backup location and retention, protects required secrets with the backup, tests restoration, and fulfills deletion obligations for its installation.
Dependency, release, and vulnerability checks
- In OpenPost
- Pins supported toolchains and dependencies and includes formatting, lint, test, race, vulnerability, secret, workflow, browser, image, and restart-smoke gates in the release process.
- On OpenPost Cloud
- Deploys an immutable image only after the release workflow succeeds and verifies readiness and the exact running revision, with rollback when readiness fails.
- Your part
- Dependency and infrastructure providers publish fixes for the components they maintain; customers report suspected vulnerabilities privately.
- If you self-host
- Tracks supported releases, evaluates security notices, updates the application and host, and verifies its own deployment and rollback path.
Operational logs, health, and monitoring
- In OpenPost
- Emits service and authentication events, exposes readiness and version endpoints, and keeps provider responses and secrets out of normalized analytics and communication records.
- On OpenPost Cloud
- Uses size-bounded system and service journals and public readiness and revision checks. It does not claim a complete command-level operator audit trail.
- Your part
- Infrastructure and social providers keep separate logs under their own controls; customers review their account and provider activity where available.
- If you self-host
- Chooses log access, retention, alerts, and monitoring and must avoid collecting secrets or more customer content than its operating need requires.
Vulnerability and incident response
- In OpenPost
- Provides a private security contact and keeps durable state needed to investigate failed jobs, authentication, and provider writes without intentionally storing reusable plaintext tokens in those records.
- On OpenPost Cloud
- Triages private reports, contains and repairs confirmed incidents, preserves only necessary evidence, notifies affected customers or authorities when required, and maintains the public incident wording on this page.
- Your part
- Report suspected OpenPost flaws privately, rotate exposed credentials, follow incident instructions, and contact the relevant provider when the event is provider-side.
- If you self-host
- Owns detection, containment, evidence, recovery, notifications, and post-incident work for its installation and coordinates with OpenPost when a product flaw is involved.
Social networks, subprocessors, and user-requested services
- In OpenPost
- Routes user-authorized provider actions through capability-specific adapters; automatic image captions use a generated thumbnail and bounded context.
- On OpenPost Cloud
- Publishes reviewed data-location, provider, transfer, and human-access facts and updates the register before a new service receives managed customer data.
- Your part
- Customers choose social, identity, stock-media, and AI-triggering actions. Each selected provider controls its service, API, logs, and provider-side data.
- If you self-host
- Chooses and configures its hosting, email, storage, AI, analytics, social apps, and optional services and publishes disclosures required for its users.
Our public record.
OpenPost currently has no incident entries in this public register. This means no incident has been disclosed here; it is not a guarantee that no security or privacy event has ever occurred.
When the operator confirms a material managed-service incident, OpenPost will add the date, affected service and data, customer action, and remediation status when disclosure is lawful and does not increase risk.
Tell us privately.
Email what happened, how to reproduce it, and the version you’re using. Please keep vulnerability reports out of public issues.
openpost+security@rgo.pt Read the security policy