TryPost: a self-hosted social media scheduler with an MCP server

The gap TryPost fills: a calendar you host yourself

Most scheduling tools are rented. You get a calendar, a queue and per-network publishing, and in exchange your drafts, your clients and your metrics sit on someone else's database, priced per seat. TryPost is the self-hosted answer to that trade. It is a Laravel application with a Vue and Inertia front end that plans posts on a month, week or day calendar, lets you drag a post to a new slot, and publishes natively through each platform's official API to Instagram, Facebook, LinkedIn, X, TikTok, YouTube, Pinterest, Threads, Bluesky, Mastodon, Telegram and Discord. The README is explicit that there is no redirect and no "finish in the mobile app" step, which is the usual failure of lightweight schedulers.

The intended user is not a solo hobbyist. Workspaces, Owner/Admin/Member roles, comments with @mentions on drafts and approval flows are listed as first-class features, which points at agencies and freelancers running a roster of brands. A brand profile carrying tone, voice, language and colors is read on every AI generation call, so the copilot output stays inside a defined voice instead of drifting per prompt. If you are one person posting to two accounts, the workspace machinery is overhead you will click past.

How publishing and the AI copilot actually fit together

The repository layout is a standard Laravel project: app/ for the domain code, routes/ for HTTP entry points, database/ for migrations, resources/ for the Vue and TypeScript front end, and a lang/ directory holding the sixteen interface languages the README lists. The front end is built with Vite, which is why package.json ships vite, @vitejs/plugin-vue and @inertiajs/vue3 together. Publishing is not a browser-side action; the composer writes a post, the calendar stores the scheduled slot, and a background job fires at that time against the platform's API. That is the only architecture that survives a closed laptop, and it is why a queue worker is part of running the thing.

The AI side is split in two. Inside the app, the copilot drafts captions, hooks, full posts and multi-slide carousels, reading the brand profile each time. Outside the app, there is a REST API and an MCP server, described as first-class, so Claude, Cursor, ChatGPT or a script can draft, schedule and publish. The repository carries .mcp.json alongside .claude/, .cursor/ and .agents/ directories, and AGENTS.md, CLAUDE.md and GEMINI.md at the root, which is consistent with the claim that assistants are a supported client rather than an afterthought. The docs site at docs.trypost.it/ai/introduction is where the README sends you for MCP setup.

Two environment variables in .env.example reveal how carefully the publishing path was thought through. X_DEFUSE_LINKS rewrites links in the X version of a post as non-clickable so X does not bill them at the link-post rate, and the comment notes that self-hosted installs publish through their own X app and pay their own bill. META_PAGE_WALK_SECONDS controls how the Facebook page walk behaves. Neither is documented in the README, which is a pattern worth noting: the .env.example file is currently the most honest description of the operational surface.

Installing TryPost and scheduling a first post

The README does not inline install steps. It points self-hosters at the installation guide at docs.trypost.it/self-hosting/overview and offers a hosted option at trypost.it. What the repository does provide is a Docker Compose setup, and that is the path worth reading before you follow the guide, because it tells you what the stack expects.

compose.yaml defines an app service built from docker/Dockerfile at the dev target, plus pgsql on postgres:16-alpine and redis. The app container maps three ports and sets TRYPOST_DOCKER_BOOTSTRAP to 1, which is the flag that triggers first-run setup inside the container:

services:
    app:
        build:
            context: .
            dockerfile: docker/Dockerfile
            target: dev
        image: trypost-app:dev
        ports:
            - '${APP_PORT:-8000}:80'
            - '${REVERB_PORT:-8080}:8080'
            - '${VITE_PORT:-5173}:5173'
        environment:
            TRYPOST_DOCKER_BOOTSTRAP: '1'

Before starting anything, copy the environment template. The example file pins PostgreSQL as the default connection and shows the MySQL alternative in a comment:

cp .env.example .env
# DB_CONNECTION=pgsql, DB_PORT=5432, DB_USERNAME=postgres
# MySQL alternative: DB_CONNECTION=mysql, DB_PORT=3306, DB_USERNAME=root

One line in that file matters more than the rest for a self-hosted install. SELF_HOSTED=true is described as skipping payment requirements, and the comment next to the connected-accounts setting says self-hosted typically wants more than one account per network per workspace, while the cloud default is false. Set it deliberately rather than inheriting the cloud behaviour.

With the containers healthy, bring the stack up. The app service has a healthcheck against http://127.0.0.1/up with a 90 second start period, so give the first boot room before concluding it failed:

docker compose up -d
docker compose ps   # app should report healthy, not just running

If you are not using Docker, the app is a Laravel project, so the usual artisan entry point at the repository root applies, and API tokens and MCP authentication run through Laravel Passport. The .env.example comments note that Passport falls back to storage/oauth-*.key when the PEM environment variables are unset, and gives the generation command:

php artisan passport:keys

The comment recommends environment variables over key files when several nodes sit behind a load balancer, because every node must share the same key pair. That is a real deployment constraint, not a footnote. Once the instance is up, connect a social account through the app, open the calendar, compose a post, pick a slot, and let the queue worker publish it. If nothing publishes, check the worker before you check the platform, because a stopped worker looks identical to a rejected post from the calendar view.

Where TryPost will disappoint you

The support matrix is the first hard boundary. Twelve networks are listed, and the README does not describe a plugin interface for adding a thirteenth. If your audience lives somewhere else, you are writing the integration yourself against the app/ code, and the AGPL means you owe those changes to your users if you run it as a service.

Native API publishing is not the same as feature parity with each network. The README says posts publish through official APIs and mentions tailoring the preview per network, but it does not enumerate which post types each platform accepts. Carousels, threads, video formats and per-network character limits are exactly where schedulers break, and the documentation is silent on the per-platform capability table. Treat the twelve logos as a list of integrations, not a promise that every feature works everywhere.

The AI copilot is a dependency you may not want. It reads a brand profile on every generation, which is the right design for consistency, but it means an external model call sits in your drafting loop. The README does not say which providers are supported or whether generations can be routed to a local model, so if your content cannot leave your infrastructure, verify that before you plan around the copilot.

Finally, the operational surface is real. Postgres or MySQL, Redis, a queue worker, Reverb on port 8080, Vite on 5173 in development, Passport keys shared across nodes, and OAuth applications registered with each network so you can pay your own API bills. The project is maintained: the last push was on 2026-09-10, and v1.0.9 was released on 2026-09-04. But the version numbers are still in the 1.0.x line, and a scheduler that fails silently at publish time is worse than a manual post, so watch the queue.

TryPost against Mixpost and Postiz

The obvious comparisons are Mixpost and Postiz, both open-source schedulers and both named in the searches around this project. The difference that matters is the interface for automation. TryPost ships a REST API and an MCP server as documented first-class features, with .mcp.json in the repository and dedicated assistant configuration files at the root. That makes it a scheduler an agent can drive, not just a scheduler with an API bolted on.

The stack differs too. TryPost is Laravel and Vue with Inertia, PostgreSQL or MySQL, and Redis, which is comfortable if your team already runs Laravel and awkward if it does not. Mixpost is also PHP and Laravel, so the operational overlap there is high and the choice comes down to features and licensing rather than runtime. Postiz sits in a different ecosystem, so teams comparing it with TryPost are usually deciding between two hosting stories and two integration lists rather than two implementations of the same stack.

The licence is the sharper distinction. TryPost is AGPL-3.0, and the README states the obligation plainly: if you run a modified version as a network service, you make your changes available to its users under section 13. If you intend to fork TryPost, add a network integration and resell scheduling as a service, that clause is the whole business decision, and it is the one thing to read before you write code. This is not legal advice; read LICENSE.md and take your own counsel.

Editorial conclusion

Adopt TryPost if you run Laravel infrastructure already, need per-client workspaces with roles and approvals, and want the scheduler on your own servers under AGPL-3.0. Do not adopt it if nobody on the team can operate Postgres, Redis, a queue worker and per-network OAuth apps, or if you need a network outside the twelve listed, since the README does not document a plugin path for adding one. Before committing, verify the twelve platform APIs against the accounts you actually hold, check that your database choice matches the supported connections in .env.example, and read AGPL section 13 if you intend to host a modified version for other people.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. trypostit/trypost on GitHub