Introducing the new Postiz agent and MCP.
You can schedule posts or multiple posts to multiple social channel from the chat.
This require ChatGPT.

Upgraded to node 22:

• Support for ESM imports from commonjs
• Better version less bug
• Changed encryption to support node 22.

What's Changed

• Postiz Agent by @nevo-david in #1027
  Full Changelog: v2.7.0...v2.8.0

Full Changelog: v2.6.4...v2.7.0

Full Changelog: v2.6.3...v2.6.4

Full Changelog: v2.6.2...v2.6.3

Full Changelog: v2.6.1...v2.6.2

Wrong Post ID on return

We have just released a new provider: Listmonk.
You can now schedule emails! With Listmonk.

What's Changed

• Fully translated into Georgian - სრულად გადათარგმნილი ქართულად by @ZurabBalamtsarashvili in #971
• logo jsx attribute fix: stroke-width -> strokeWidth by @Dforrunner in #970
• Fix Georgian translation for cancellation message by @ZurabBalamtsarashvili in #980

New Contributors

• @ZurabBalamtsarashvili made their first contribution in #971
• @Dforrunner made their first contribution in #970

Full Changelog: v2.5.4...v2.6.0

• Added a disconnect on Prisma nestjs shutdown hook, to remove the connection and save resources.
• Preview date rendered the local date on the server side, which caused it to show an irrelevant date.
• Tiptap editor send > and < and this is how it is published on social media, added a replace.

Full Changelog: v2.5.3...v2.5.4

Full Changelog: v2.4.3...v2.5.3

We have had some problems with concurrency for a hefty load (primarily for Postiz cloud).

Here are the changes we have implemented:

• Workers can now reach a maximum of 300 concurrent jobs.
• Bottleneck JS timeout (expiration) is set to 60 seconds for a single HTTP request; if it fails, it returns to the user "Something is wrong with ${identifier}"
• Max Stalled jobs changed to 10.
• Cron for missing jobs - fixed.

Ideology behind the change:
Until recently, Postiz added posts to the queues and processed them without any concurrency, which works great with open-source instances that are not automated.

However, the problem was the restrictions of social media platforms - what if I want to post 10 posts to Instagram at the same time? If Instagram has a concurrency limit per second, what is the maximum number of requests that I can make?

Instagram will throw you off with a rate limit error.
So we needed a better solution to make "http" requests, wait between multiple workers.
So only X requests could run concurrently, and wait for the other requests.

Since you may want to run multiple workers simultaneously, the solution must be Redis-supported and not limited to local execution.
So libraries like p-queue would not be sufficient.

Another thought we have is to move to bullmq-pro, which would make concurrency of the entire job (not HTTP request)
The main problem was that it costs money, so it's hard to push it into the open-source, although it would probably be the easiest solution.

Bullmq-pro allows you to create concurrent jobs based on groups - so a group can be, for example, "LinkedIn" or "Instagram". So, as promised, only one concurrent job will be run at a time on the social platform.

In any case, I hope these transparent updates provide you with some clarity.

Full Changelog: v2.5.2...v2.4.3