CraysPostiz
Postiz is the app you open when Nostr is part of your publishing discipline, not your whole social world: one calendar, many channels, scheduled notes, media, approvals, analytics, API calls, CLI commands and MCP tools.
Nostr as a channel, not a home
Postiz feels obvious if you already run a public calendar. You have an announcement going to X, a polished version for LinkedIn, a shorter note for Bluesky, a community reminder in Discord, a thread for Mastodon, maybe a Telegram post, maybe a WordPress article, and now you want Nostr in the same rhythm. You do not want to copy the same idea by hand seven times. You want a composer, a calendar, a queue, a place for drafts and a reliable release time.
That is the room Postiz builds. The home page calls it an agentic social media scheduling tool for 30+ networks. The repository describes it as an alternative to Buffer, Hypefury and Twitter Hunter. The README says it schedules posts, measures work with analytics, supports team collaboration, exposes automation through API flows and currently keeps the hosted and self-hosted versions functionally aligned. The Nostr page narrows that wide pitch: schedule Nostr notes in bulk, broadcast them to relays, manage replies from one dashboard, publish alongside 28+ other channels, and keep a shared calendar.
For this archive, the distinction is important. Postiz is not Nostr-native in the way a feed client is Nostr-native. You do not open it to wander through the relay graph, follow a thread, inspect someone else's event, manage lists or live in a Nostr social identity all day. You open it because publishing has become work. In that work, Nostr is one output. It can be a first-class output, but it is still an output.
That makes Postiz useful and slightly uncomfortable. Useful, because many people will only keep Nostr alive in their communication if it fits their existing publishing process. Uncomfortable, because Nostr's best habit is direct signing and direct relay control, while scheduling asks you to let something else sign later. Postiz sits right on that tradeoff.
What Postiz actually publishes to Nostr
The public Nostr channel page says Postiz can queue Nostr notes, pick a publish time and broadcast to configured relays. It advertises bulk scheduling, multi-relay broadcasting, notes with media, threaded replies, analytics around reactions, reposts, zaps and follower growth, and Nostr automation through the Public API or MCP. The FAQ is specific enough to be checked against the code: scheduled notes are signed and published as Nostr notes, replies are sent as kind 1 events with e and p tags pointing back to the parent event and author.
The backend provider confirms the core. libraries/nestjs-libraries/src/integrations/social/nostr.provider.ts imports getPublicKey, Relay, finalizeEvent and SimplePool from nostr-tools. The class is named NostrProvider. The provider identifier is nostr, the provider name is Nostr, the editor mode is normal, and the maximum length is 100000 characters. Its frontend companion at apps/frontend/src/components/new-launch/providers/nostr/nostr.provider.tsx is deliberately plain: PostComment.POST, no custom settings component, no custom preview component and the same large maximum.
Publishing is simple in the code. The provider builds content by taking the message and appending media paths separated by blank lines. It finalizes a kind 1 text note with empty tags for a normal post, current timestamp and the private key. Then it publishes that event to a fixed relay list: wss://nos.lol, wss://relay.damus.io, wss://relay.snort.social, wss://temp.iris.to and wss://vault.iris.to. It returns a release URL on Primal: https://primal.net/e/{eventId}.
Replies use the same kind 1 event type, but with tags. Postiz picks the latest comment id or the original post id, builds an e tag marked as reply and adds a p tag for the author key. That is not a full Nostr client, and it is not pretending to be one. It is a scheduler that knows enough Nostr to write notes and replies into a handful of public relays.
That narrowness is good to know. Postiz does not appear, from the current provider code, to read your relay list event and dynamically choose the places you normally publish. It does not expose per-post relay selection in the Nostr provider settings. It does not model zaps, long-form NIP-23 articles, communities, lists, NIP-65 outbox discovery or NIP-07 browser signing for scheduled approval. The public page talks about chosen relays and configured relays, while the provider code uses a fixed list. That gap may close over time, because the repo moves quickly, but the current reading stays with current evidence.
This is why Postiz should be praised for what it actually does. It brings Nostr into a professional publishing calendar. It does not turn Nostr into a full campaign operating system by itself. When you schedule a plain note, the result is useful and portable enough: a kind 1 event that another Nostr client can render. When you need a deeply Nostr-native workflow, the calendar is only the start of the conversation.
The private key problem
This is the part you should read slowly. Postiz's Nostr provider asks for a Nostr private key as a custom field. The label in code is Nostr private key, the field type is password, and the tooltip tells the user to provide a hex private key, with a note that websites like iris.to can expose it. The backend takes that key, derives the public key with getPublicKey, fetches profile metadata from relays, signs a long-lived JWT containing the password, and later retrieves that password to finalize scheduled events.
There is a technical reason for this. A scheduler has to publish when you are not sitting there approving a signer popup. If the tool cannot sign at the scheduled moment, it can only remind you to sign. Postiz chooses the practical scheduling path: store signing authority so it can publish the note later. That is what makes the tool useful for teams and automation, and that is also why this page should not sell it casually to every Nostr user.
If you use Postiz for Nostr, do not hand it the private key to your main identity just because the button is convenient. Use a dedicated publishing key when the workflow allows it. If you are running your own instance, understand where secrets live, who has server access, how backups are handled and whether your threat model fits this kind of scheduler. If you are using the hosted cloud, read it as a custody-adjacent workflow for signing power, even if Postiz's compliance language is strong around platform OAuth and not asking users for API keys on mainstream social networks.
This is not a cheap complaint. It is the central design tension. Postiz can be excellent at the job it chose and still be the wrong tool for a user who treats their Nostr key like a passport. The right sentence is not "never use it". The right sentence is: use it when scheduled publishing is worth the key-management tradeoff, and isolate the risk like a grown-up.
A careful creator can make that tradeoff practical. Create a separate Nostr identity for scheduled brand posts. Keep your personal account in a signer-controlled client. Put the scheduled account's npub in your profile, explain what it is for, and treat it like a press desk rather than your private voice. That way Postiz can do its useful work without becoming the one place where your whole Nostr life can be compromised.
Calendar, API, CLI and MCP
Postiz becomes more interesting when you stop imagining only the web UI. The docs describe a Public API with posts that can be created as now, schedule or draft. For Nostr, the provider settings schema is minimal: the settings block only needs "__type": "nostr". The integration id selects the connected Nostr channel. The post content, images and date live at the post level, just like other platforms.
That API shape is important for automation. A team can generate drafts in a CMS, upload media through the Postiz upload API, schedule the Nostr version of a release note, and let the same publishing run hit other connected channels with platform-specific settings. The docs list 27 supported platform setting types in the Create Post reference, including Nostr, X, LinkedIn, Facebook, Instagram, Threads, Bluesky, Mastodon, Warpcast, VK, YouTube, TikTok, Reddit, Lemmy, Pinterest, Discord, Slack and Telegram.
Then there is the CLI. The Postiz CLI wraps the Public API so you can manage integrations, schedule posts and upload media from the terminal. The docs also point to gitroomhq/postiz-agent, a separate TypeScript repository created on 2026-02-14 and pushed on 2026-06-02, with 276 stars, 50 forks and 7 open issues at this check. That repo exists for agent workflows: Claude, OpenClaw and similar tools can talk to Postiz as a publishing layer.
The MCP docs make the same direction clearer. Postiz exposes an MCP server with 9 tools: list integrations, list groups, read platform schemas, trigger platform-specific helpers, schedule or draft posts, generate images, list video options, read video function settings and generate videos. The MCP endpoint accepts an API key or OAuth token. That is the new Postiz personality: not only a calendar UI, but a programmable outlet for agents and workflows that need to put content somewhere at a particular time.
The stack and self-hosting
The GitHub repo is large and alive. At the time of this check, gitroomhq/postiz-app was not archived, used TypeScript as its primary language, carried an AGPL-3.0 license, and showed 31545 stars, 5827 forks and 166 open issues and pull requests combined through the GitHub API. It was created on 2023-07-08 and pushed on 2026-06-05. The latest visible release was v2.21.8, published on 2026-05-22, following a steady run of v2.21.x releases through March, April and May 2026.
The architecture docs describe three main services and four external services. The main services are the frontend, backend and orchestrator. They usually run in a single Docker container and talk over HTTP. The external pieces are SQL database, Redis, Temporal and storage. The backend coordinates real work, talks to the database and Redis, and triggers Temporal workflows. The orchestrator runs scheduled publishing, token refreshes, notifications, missing-post checks and posting streak work. Temporal is the durable scheduling engine, which fits the product: if you sell scheduled publishing, time itself becomes infrastructure.
The code stack lines up with that. The root package uses Next.js and NestJS, Prisma with PostgreSQL by default, Redis, Temporal, Sentry, Stripe, OpenAI SDK pieces, LangChain, Mastra MCP packages, Tiptap, Tailwind, Vite, Jest, Vitest and many platform SDKs. It includes nostr-tools version ^2.18.2. Docker Compose files wire Postgres, Redis, Temporal, Temporal UI, Elasticsearch for Temporal and environment variables for storage, OAuth, APIs, billing and uploads.
Self-hosting is real, but not tiny. The system requirements page says a small team can start at 2 vCPU and 2 GB RAM for light use, while 4 vCPU and 8 GB RAM are recommended. It calls the official Docker Compose path canonical, with postiz-docker-compose pre-wiring Postiz, Postgres, Redis and Temporal. The Docker Compose docs warn that services and variables change across releases and point users to the repository rather than a stale copy. This is not a one-file toy scheduler. It is a production-shaped app with production-shaped maintenance.
Who built the room
Postiz is publicly tied to Gitroom and Nevo David. The Postiz Product Hunt announcement, published on 2024-11-20, names Nevo David and labels him Founder of Postiz. Gitroom's own site says Nevo David is founder of Postiz.com and describes growth from 3k GitHub stars to 14k in three months. The active GitHub organization is gitroomhq, and the README points to Gitroom-flavored project surfaces: the main app, public API, Node SDK, n8n node, Make.com integration, Discord, YouTube tutorials and OpenCollective sponsorship.
The community story is easy to see in older public posts as well. Reddit threads trace the app from a smaller open-source scheduler with 9 channels, then 14, then 18, then 19 and eventually 25+ channels. One r/selfhosted update around v1.39.2 specifically introduced MCP servers. Another later thread listed Nostr among the supported channels. The project grew in public, with the usual open-source mixture of excitement, installation support, feature requests and skepticism.
That history matters because Postiz's Nostr support did not emerge from a Nostr-only culture. It emerged from a scheduler trying to cover the channels modern creators actually use. In some ways that is exactly why it belongs here. Nostr will not reach everyone by asking them to abandon their existing publishing operation. It will also reach people through tools that add Nostr as another serious destination.
Where Postiz is useful, and where it is not
Use Postiz for Nostr when you run a repeatable publishing process. A newsletter wants the same release note on Nostr, Mastodon, LinkedIn and Bluesky. A founder wants a week of launch notes scheduled before travel. A community team wants drafts reviewed before they go live. A developer wants an API call to publish an announcement from a release workflow. An agent wants to turn a content plan into scheduled posts without making a human click through every platform. This is the Postiz zone.
Do not use Postiz as your primary Nostr brain. It is not built to replace a client for reading, discovery, following, relay selection, lists, zaps, long-form reading or key culture. It publishes kind 1 notes and replies. It does not try to explain the whole protocol to you. It does not make your Nostr identity safer by itself. It adds discipline and automation to one specific act: putting notes onto relays at the right time.
The final test is honest: after Postiz publishes, can you open the result in another Nostr client? The provider returns a Primal event URL, which is a practical bridge back into the Nostr world. The event itself is a kind 1 note, so the result should be legible to the ordinary client ecosystem. That is the good news. The remaining caveat is all upstream: the scheduler got the authority to sign the note. Decide with your eyes open.
Postiz earns its place in the App Hub because it shows one of the less romantic paths into Nostr. Not every user arrives through cypherpunk curiosity. Some arrive through a calendar, a campaign, a workflow, a launch checklist, an API call or an agent. If Postiz helps them include Nostr without breaking their week, that is real adoption. Just do not confuse the publishing machine with the whole network.
Sources worth opening
These sources separate the product pitch from the code reality: official pages for the scheduler, docs for API/MCP/self-hosting, the active GitHub repo, the Nostr provider implementation and public background on the project.
- Postiz Nostr scheduler page
- Postiz official home page
- gitroomhq/postiz-app GitHub repository
- Postiz README
- Postiz package.json
- Postiz Nostr backend provider
- Postiz Nostr frontend provider
- Postiz integration manager
- Postiz provider settings type map
- Postiz architecture documentation
- Postiz system requirements
- Postiz Docker Compose installation docs
- Official postiz-docker-compose repository
- Postiz Public API create post reference
- Postiz Public API Nostr provider settings
- Postiz CLI documentation
- Postiz MCP introduction
- Postiz MCP tools reference
- gitroomhq/postiz-agent repository
- Postiz v2.21.8 release
- Postiz Product Hunt announcement
- Gitroom site and founder profile
- Postiz Node SDK package
- Postiz n8n node package
- Postiz Make.com app
- Postiz v1.39.2 MCP discussion on r/selfhosted
- Postiz v1.58.0 thread listing Nostr support
