TryPost: a self-hosted scheduler that publishes through twelve platform APIs
Open-source Social Media Scheduling
At a glance
- What is it?
- TryPost is an AGPL-3.0 Laravel and Vue application that puts scheduling, an AI copilot and an MCP server behind one calendar. The README is strong on features and thin on the operational detail that decides whether self-hosting is worth it.
- Who is it for?
- Adopt TryPost if you already run PHP infrastructure, need to keep drafts and metrics on your own servers, and want an MCP server so an assistant can schedule posts. Do not adopt it if you have no PHP or queue operations experience, or if you expect the README to tell you how to register OAuth applications with twelve platforms, because it does not.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap TryPost is aimed at
Most scheduling tools are closed services. You hand over your drafts, your connected accounts and your engagement metrics, and you accept whatever feature set the vendor ships next quarter. TryPost takes the opposite position. The README states that self-hosting keeps posts, drafts and metrics on your own infrastructure, and the licence permits commercial use, modification and redistribution. The pitch is aimed at two groups: agencies or freelancers running a roster of brands who want workspace isolation and approval flows without paying per seat, and technically capable creators who would rather run a server than rent one. The README also lists a cloud option at trypost.it for people who want the same product without the setup. That dual model matters when you evaluate the project, because the self-hosted path is the one the repository actually documents.
Native publishing to twelve networks, and what that implies
The README is explicit that posts publish natively through each platform's official API, with no redirect to a mobile app to finish the job. The supported list is Instagram, Facebook, LinkedIn, X, TikTok, YouTube, Pinterest, Threads, Bluesky, Mastodon, Telegram and Discord. Native API publishing is a different engineering problem from link sharing. Each network has its own OAuth flow, media upload rules, character or aspect ratio constraints and rate limits, and the composer has to reconcile them. TryPost's answer is a multi-platform composer where you write once and then tailor the preview per network in parallel. That design choice has a cost: the twelve integrations are twelve ongoing maintenance surfaces, and a single API change on one network can break scheduling for that network alone. The README does not describe how failures are surfaced or retried, so treat integration resilience as something to inspect in the code before you depend on it.
The AI copilot, the brand profile and the MCP server
Three AI-related features are described. The copilot generates captions, hooks, drafts and multi-slide carousels, and the README says it reads your brand profile on every generation, where the brand profile holds tone, voice, language and colors. The carousel builder turns a prompt into a multi-slide carousel with images. The third piece is the one that separates TryPost from most schedulers in this category: a first-class MCP server plus a REST API, so Claude, Cursor, ChatGPT or your own scripts can draft, schedule and publish. According to the README, this is a supported integration path rather than an afterthought, and there is a setup page at docs.trypost.it/ai/introduction. What the README does not state is which model providers the copilot calls, whether you supply your own API key, or what happens to prompt data. For a self-hosted tool whose selling point is data ownership, that omission is the first thing to resolve.
Getting it running: what the README gives you
The repository does not include an installation section. The README points to docs.trypost.it/self-hosting/overview and describes self-hosting as free forever, your servers, your data. The stack is visible from the repository metadata and topics rather than from prose: PHP with Laravel on the server, Vue on the front end, with a queue and scheduler implied by the fact that posts must be published at a future time. That means a working deployment needs a web server, a database, a queue worker and a cron entry, and the documentation is where the exact commands and config keys live. Because I have not installed it, I cannot give you the .env keys, the artisan commands or the minimum PHP version. Anyone evaluating TryPost should read the self-hosting guide first and confirm it names concrete versions and a supported database before planning a deployment.
Where the README leaves you on your own
The feature table is long and the operational detail is short. Nothing in the README explains how you register OAuth applications with twelve platforms, which is unavoidable work: every network requires you to create an app, obtain client credentials and configure redirect URIs. Nothing describes storage requirements for the asset library, which holds workspace media and integrates Unsplash and Giphy search. Nothing describes backup or migration procedure for the database that holds your scheduled queue. Nothing states how the AI copilot is configured or billed. The README also lists sixteen interface languages, which is a translation surface that needs maintenance with each release. None of these are reasons to reject the project, but they are the difference between a demo and a deployment, and the README does not close that gap.
A fair comparison: Postiz
The closest open-source alternative is Postiz, which also targets self-hosted multi-network scheduling. The difference in approach is scope of the AI surface. Postiz centres on the scheduling calendar and the platform integrations, while TryPost treats the AI copilot, the brand profile and the MCP server as first-class parts of the product, with the README describing agents as a primary way to drive it. If your workflow is human-plans-then-publishes, the extra AI layer is surface area you maintain without using. If your workflow is an assistant drafting and scheduling on your behalf, TryPost's MCP server is the reason to pick it, and the REST API means you are not locked into one assistant. Both projects carry the same fundamental burden: you own the OAuth applications and the integration breakage. The choice is about which additional layer you want to run, not about avoiding that burden.
Licence, releases and the cost of staying current
TryPost is AGPL-3.0. The README summarises the terms: use, modify, fork, self-host and redistribute, including commercially, with the section 13 condition that if you run a modified version as a network service you make your changes available to its users. For an agency hosting TryPost for its own clients, that condition is the one to read carefully with your own counsel; I am not giving legal advice, and the LICENSE.md file is the authoritative text. On releases, the repository shows v1.0.9 on 2026-09-04, v1.0.8 on 2026-08-27 and v1.0.7 on 2026-08-09, with the last push to main on 2026-09-10. That cadence means upgrades arrive every few weeks. Each upgrade is a chance for a platform integration to change, so plan for a staging instance and a migration step rather than pulling main into production. The README does not describe a release or upgrade policy, so version pinning is on you.
Editorial conclusion
Adopt TryPost if you already run PHP infrastructure, need to keep drafts and metrics on your own servers, and want an MCP server so an assistant can schedule posts. Do not adopt it if you have no PHP or queue operations experience, or if you expect the README to tell you how to register OAuth applications with twelve platforms, because it does not. Verify before committing: the self-hosting guide at docs.trypost.it/self-hosting/overview, the exact PHP and Node versions it requires, the queue and cron configuration it assumes, and how your organisation will satisfy AGPL section 13 if you modify the code and expose it to users.
Community notes