Your approval, your machine, your keys

What pendpost guarantees

• Nothing publishes without approval. Every post is fail-closed: it is created as a draft, and the scheduler skips anything that is not approved.
• Approval is a separate authority. Drafting a post and approving it are distinct steps. By default you hold the approval, or you record it under an auto-approve policy only you enable.
• Autonomy is owner-only and opt-in. Auto-approve stays off until you turn it on, and only the owner can change that policy.
• Your keys stay on your machine. pendpost binds 127.0.0.1, reads credentials from your own .env, and never phones home.
• A brake against bans. A platform action block halts that lane and does not auto-resume until you clear it.

Does anything publish without my approval?

No, not by default. Every post in pendpost carries an approval state, and the system is fail-closed: a post with no approval will not publish. Creating a post always produces a draft, the scheduler skips anything that is not approved, and only an explicit approve or reject changes that state. The gate is the core of the design, not a setting bolted on afterwards. The same idea drives the brakes and the brand-lint described on the differentiators section of the home page.

Can an agent publish on its own?

Not by default. Nothing publishes until it's approved, and by default that approval is you. An agent operating pendpost (an MCP client such as Claude, for example) can draft and schedule all day, and the drafts wait for approval. Approval is a separate authority: you hold it, or you record it under an auto-approve policy only the owner can enable and revoke. This holds on both faces: the agent interface and the web dashboard run the same contract, enforced by a parity test, so the agent face has no privilege the dashboard lacks.

Who can turn on autonomous posting?

Only the owner. pendpost supports progressive autonomy: you can opt into an auto-approve policy that lets it publish matching posts on its own, so you scale from approving every post to fully hands-off. Two things keep that safe. Enabling auto-approve is owner-only, so a request from any other actor is refused. And when the policy approves a post, that approval is recorded under a distinct policy actor, never under the agent, so autonomy is something you grant, not something an agent grants itself. Brand-lint, the circuit breakers, the cadence cap, and your schedule still gate every publish. You own the policy and can switch it off at any time.

Where do my credentials and data live?

On your own machine. pendpost is local-first: it binds to 127.0.0.1 by default, your platform API credentials stay in your own .env file (readable only by your user account), and nothing phones home, so we receive nothing from your install. Your tokens are sent only to the platforms you configure (Instagram, Facebook, LinkedIn, YouTube, X), never to us. Because it binds to loopback, there is no login to manage: the perimeter is your own machine. pendpost also rejects cross-origin browser requests and unknown Host headers, which closes the browser-based attacks that loopback alone would not. If you deliberately expose it on a network, a bearer-token gate turns on. The website itself sets no tracking cookies; see the privacy policy.

How does pendpost protect my accounts from bans?

With circuit breakers. When a platform returns an action block, such as Meta error 368, pendpost trips a breaker that halts that lane and does not auto-resume, because such a block carries no machine-readable clear time. The owner clears it explicitly once the platform lifts it, and while a lane is blocked, even health checks send no traffic to that platform. A cadence cap defers bursts instead of firing them, so an over-eager agent cannot get your account suspended. You remain responsible for each platform's terms, but the brakes are there to keep an automated workflow from tripping them.

What about the optional 24/7 cloud service?

pendpost is free to self-host, and that free core is the whole product. For people who would rather not run the box themselves, there is an optional 24/7 cloud service run by Nomadik GmbH. It keeps the live lanes publishing around the clock, holds platform tokens in an encrypted vault rather than a plaintext file, and enforces the same human approval gate server-side, with an auditable runtime and a clean way to eject back to self-host. The 24/7 cloud service sells uptime and convenience, never extra capability, and the approval rules are identical to the ones above.

How does this compare, and what does pendpost not claim?

Hosted social tools hold your accounts in their cloud and ask you to trust their servers. pendpost runs on your machine instead, so its trust boundary is honest: because it is local-first, anything that can already read your files as your own user can read your credentials too, exactly as with any tool that keeps keys on disk. Securing your machine, your account, and your backups is yours to manage. pendpost defends the layers above that: the approval gate, cross-origin and DNS-rebinding defenses, isolation between client workspaces, and a discipline of never writing a secret to a log. For how it stacks up against other options, see the alternatives page and the head-to-head with Postiz. For the wider workflow, see letting an AI agent run your social.

More questions are answered on the FAQ, and because pendpost is MIT-licensed, the security design is yours to read or audit in the source.

Last reviewed: 22 June 2026.