How your keys are held.
A scheduler holds credentials to your audience. This page states plainly how they’re stored, how they’re used & how they’re destroyed.
5 commitments.
Not aspirations — descriptions of how the system works today.
- Tokens encrypted before they’re stored
- Your social account credentials are locked with industry-standard authenticated encryption before they are stored.
- Every connection through the platform’s own front door
- Nine of the ten featured networks use the platform’s official connect and permission screens. Bluesky uses a separate app password you create and revoke inside Bluesky — never your account password. Publishly does not automate a browser login.
- API keys you can limit and revoke
- Give each key only the access it needs and revoke it at any time. A full key is shown once and is never stored in a form Publishly can reveal later.
- An audit trail that answers questions
- Team invitations, channel changes, key management & bulk operations are recorded per workspace — who, what, when, from where.
- Client isolation by design
- Workspaces keep every brand’s accounts, tokens, media & history separate — a client’s data leaves with them, cleanly.
Security here is mostly subtraction — fewer copies of each credential, less access on every key, and a written record of what changed.
How client data stays separated.
The separation is enforced every time data is read or changed, and tested against the real API.
- One workspace never sees another
- Every data request checks the workspace it belongs to. Automated tests prove that one customer cannot read or change another customer’s private data.
- Roles decide, the audit log records
- Channels, media, keys & analytics live inside a workspace. Roles & invitations decide who can act; the audit log records who did.
- Deletion is destruction
- Disconnect a channel & its tokens are destroyed immediately. You can export your workspace at any time.
The platform underneath.
Transport, sign-in, keys & logging — the controls a security review asks about.
- HTTPS everywhere, and nowhere else
- TLS terminates at the edge and plain HTTP redirects to the canonical HTTPS origin. HSTS is sent with a one-year max-age covering subdomains, so browsers refuse to downgrade.
- Hardened browser defaults
- Responses carry a content-security policy that forbids framing, X-Frame-Options DENY, nosniff, and a referrer policy — checked against the live origin by the launch audit before a release goes out.
- Sign-in and session handling
- Passwords are hashed with bcrypt and never stored or logged in readable form. Sessions are carried in an HTTP-only cookie the page script cannot read, and a request throttle applies across the API — including sign-in — to blunt credential stuffing.
- Least privilege on every key
- API keys are scoped to a workspace and revocable at any time. A full key is displayed once at creation and cannot be read back afterwards — losing it means rotating it, not recovering it.
- Operational logging
- Delivery attempts, publish results, failures and their classified reasons are recorded per workspace, alongside an audit trail of team, key and channel changes. Access tokens and post credentials are excluded from log output.
Found a vulnerability?
Write to phliq5215@gmail.com before disclosing publicly. Include a concise reproduction, and never put access tokens or customer data in the email. We read every report and will tell you what we found and when it is fixed.
What we do not claim: Publishly holds no SOC 2, ISO 27001, PCI DSS or HIPAA certification, and there is no third-party audit report to share. If your procurement process requires one, tell us before you buy so nobody is surprised later.
Read the code.
Built on the open-source Postiz engine (AGPL-3.0). The corresponding source of the running service is available to every user.
Read it, then start.
Get started free