Self-Hosted Social Media Scheduler: The Three-Layer Bill, and the Checklist for When Not to Self-Host

The pitch is clean: stop paying forty dollars a month, run the thing yourself, own your data. The pitch is also the cheapest line on the invoice you are about to pick up.

Before anything else, an honest note about the search data behind this page. The phrase "self hosted social media scheduler" barely gets typed. Autocomplete returns two real variants - the phrase itself and a "planner" spelling - and the rest of the family is noise from an unrelated cooking sense of "self hosted". We are not going to pretend that is a groundswell. The fat query family sits one step upstream, at open source social media scheduler, which fills all ten slots. That ordering is itself the finding: people arrive at self-hosting through open source, not the other way round. They go looking for free software, discover it has to run somewhere, and only then ask the question this page answers.

Self-hosting does not remove a bill. It converts one recurring payment into three: a machine, a set of platform credentials, and your own attention.

Layer One: The Server, and What the Vendor Admits It Needs

Postiz is the most-searched self-hostable scheduler right now, and to its credit it publishes a floor. Checked on 2026-09-20, its system requirements page states a minimum of 2 vCPU, 2 GB RAM and 20 GB disk - annotated "all-in-one, light use" - and a recommendation of 4 vCPU, 8 GB RAM and 50 GB plus a persistent volume for uploads for a team of up to twenty.

Read the services list next, because it matters more than the RAM number: PostgreSQL 14, Redis 6, and Temporal - required since v2.12.0. That last one is the part people miss. Temporal is a workflow engine, not a library; it is a long-running service with its own resources. So the "minimum" box is expected to hold an application, a database, a cache and a workflow engine simultaneously. Two gigabytes is a floor, and floors are where things fall through. The detailed version of that arithmetic is in Postiz Self-Hosted: What "Free" Actually Costs You.

The alternative shape is a paid one-time licence. Mixpost, checked the same day, sells on the line "One-Time Payment, No Monthly Fees" - a free open-source Lite edition, Pro at $299 and Enterprise at $1,199, each with one year of free updates. The sentence to notice is the one after: "you can continue using the software, but you will not receive updates unless you renew." That is not a trap, it is an accurate description of what a perpetual licence is. But it means year two is a decision, not a default - and on a stack that talks to nine platform APIs, running unupdated is a slow bleed. Our breakdown of that licence shape is in Mixpost Pricing: One Time, and What That Buys.

Layer Two: The Credential Wall, Which Is Where Projects Die

Here is the part no hosting guide covers. A hosted scheduler already holds an approved developer app with every platform. When you self-host, you become the developer, and you apply yourself - once per platform.

The clearest published example of what the unapproved state looks like is TikTok's, and it is worth reading literally. TikTok's content-sharing guidelines, checked 2026-09-20, state: "Unaudited API Clients can allow up to 5 users to post in a 24 hour window." The same documentation adds: "Unaudited API Clients can only post contents in SELF_ONLY viewership." The getting-started docs put it a second way - "All content posted by unaudited clients will be restricted to private viewing mode."

Sit with that for a second, because it is the single most consequential fact about self-hosting a multi-platform scheduler. Until you pass the audit, your instance publishes to TikTok privately, for at most five users a day. Everything will look like it worked. The API returns success. The video appears in the account. Nobody can see it. We covered that specific failure mode in The Five-User Ceiling That Decides Whether Yours Works.

Multiply that shape across however many platforms you need, each with its own review queue, its own policy reading of what your app is for, and its own turnaround. Postiz's own vendor materials concede that social app approval can take a long time - a rare case of a vendor documenting a cost that makes its own product look slower. We chased the published numbers on that in How Long Does Social Media App Approval Take?.

Layer Three: The Job That Does Not End

The third bill is paid in attention, and it recurs whether or not you are thinking about it.

• Tokens expire. Every connected account has a refresh cycle. When one lapses, posts fail silently, and the failure surfaces as "why did nothing go out yesterday".
• Platform APIs move under you. Not hypothetically - X relocated its chunked media upload from the old command-style path to dedicated v2 endpoints, and code written against the old shape simply stops. A hosted vendor absorbs that migration. You do not.
• Upgrades are yours. Postiz making Temporal mandatory at v2.12.0 is exactly the kind of change that turns a routine bump into an evening.
• Backups are yours. Your scheduling queue, media library and connected-account state now live on a disk you are responsible for.

The Reverse Checklist: When You Should Not Self-Host

Most articles on this topic only argue one direction. Here is the other one. If two or more of these are true, self-hosting will cost you more than it saves.

1. You are one person. The three-layer bill is fixed cost. It amortises across a team and it does not amortise across you.
2. Nobody owns the server outside working hours. A scheduler's whole value is that it posts when you are not there. If it breaks when you are not there, you have bought a more expensive way to miss your slot.
3. You need a platform whose API you are unlikely to get approved for. Read the intended-use language before you commit a weekend. Some platforms explicitly say the API is not for posting to accounts you or your team manage - see TikTok's API Says Out Loud That It Is Not for Posting to Your Own Accounts.
4. Your real constraint is the number of accounts, not the monthly fee. Self-hosting removes a subscription; it does not remove a platform's per-app ceilings.
5. You cannot name the data you are protecting. "Data ownership" is a real reason when you can say what data and what risk. When you cannot, it is a mood, and moods are expensive to host.

The honest positive case: self-hosting is strongest when you have a team, an existing server, a real data-residency requirement, and someone who already enjoys this kind of maintenance. It is also a genuinely different answer from "run the browser locally on your own machine with your own logins" - that approach skips the credential wall entirely because there is no developer app in the middle, at the cost of the machine needing to be on. Two different trades. Pick deliberately.

Frequently Asked Questions

Is a self-hosted scheduler actually free?

The software can be. The deployment is not. At Postiz's published minimum you are renting a machine that holds an app, PostgreSQL, Redis and Temporal at once, and that is before storage for media. Add the developer-credential work per platform and the ongoing token maintenance, and "free" describes the licence rather than the project.

Why does my self-hosted instance post to TikTok but nobody sees the video?

Almost certainly because your API client has not passed the audit. TikTok documents that unaudited clients are restricted to SELF_ONLY viewership - private viewing mode - and to at most five posting users in a 24 hour window. The integration is working exactly as specified; the specification is the problem, and the fix is the audit, not the code.

Is a one-time licence like Mixpost cheaper than a subscription?

Over a long enough horizon, yes on the licence line. But compare honestly: the one-time fee includes one year of updates, after which continued use is fine and continued updating is not. On a stack wired into nine moving platform APIs, treat the renewal as part of the running cost rather than an optional extra, and compare that total against the subscription you were escaping.