BrightBean Studio: a self-hosted Django scheduler for agencies running many client accounts
Open-source, self-hostable social media management platform. Schedule, publish, and manage content across 10+ platforms from a single dashboard. Free alternative to Buffer, Sendible, and SocialPilot.
At a glance
- What is it?
- BrightBean Studio is an AGPL-3.0 Django application that publishes to more than ten social platforms through first-party APIs, with no per-seat or per-channel limits. The trade-off is that you supply every developer app credential and operate the stack yourself.
- Who is it for?
- Adopt BrightBean Studio if your agency or in-house team already runs Django or Docker workloads and you are willing to register your own developer apps with each platform you publish to. Do not adopt it if you need a vendor to hold the API keys, if you publish only to one network, or if you cannot absorb the maintenance that comes with twelve integrations.
- 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 Python, 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 billing model BrightBean Studio is built against
Sendible, SocialPilot and Buffer price by seat, by connected channel, or by workspace tier. An agency holding twenty client accounts across four networks hits the top of those brackets quickly, and the README puts the alternative at $100 to $300 per month. BrightBean Studio attacks that specific line item. The README states there are no per-seat, per-channel or per-workspace limits and that every feature is available to every user, with no paid tier and no feature gate.
The intended user is not a solo poster. It is someone managing many client accounts under one roof, which is why the data model starts at organisations, then workspaces, then members, and why a separate Client role exists for external collaborators who should not see the rest of the agency's work. The README also offers a hosted instance at brightbean.xyz/studio, so self-hosting is a choice rather than the only path. That matters: the project is competing on cost structure, not on the promise that running your own server is inherently better.
Direct first-party APIs instead of an aggregator
The architectural decision that shapes everything else is stated plainly in the README: platform integrations talk directly to official first-party APIs using your own developer credentials, with no aggregator middleman. Tools in this category often route through a service that has already been approved by each network, which spares you the app registration process and absorbs the API churn. BrightBean Studio gives that up deliberately.
The consequence is visible in the support matrix. Facebook, Instagram and Instagram Direct carry publish, comments, DMs and insights. LinkedIn appears twice, as personal and company, both with publish, comments and insights but no DMs. TikTok and Pinterest publish and report insights but expose no comments or DMs. Bluesky and Mastodon publish and handle comments but have no insights column filled. Google Business Profile publishes and reports insights only. That uneven grid is the honest shape of first-party API access, and it is a better guide to fit than any feature list, because it tells you which platforms will feel complete and which will feel like a publishing pipe with nothing attached.
Queues, slots and the publishing engine
Scheduling is organised around two mechanisms the README names. Recurring weekly posting slots are defined per account, and named queues auto-assign posts to the next available slot. This is the classic agency pattern: instead of picking a timestamp for each post, you define the shape of a week per client account and drop content into a queue that fills the next open position. It removes a repeated decision from the operator's day.
Behind that sits the publishing engine, described as direct integrations with automatic retries, per-account rate-limit tracking and a 90-day publish audit log. Per-account rate-limit tracking is the detail worth noting, because rate limits in these APIs are scoped to the credential and the account, not to your installation. The engine also has to run outside the request cycle, since a scheduled post fires when nobody is looking at a dashboard. The README does not describe the worker or scheduler topology, so treat the deployment shape as something to confirm in the repository before you plan capacity.
Approval sits on top of the same pipeline with configurable stages: none, optional, internal, or internal plus client. Client approval runs through a passwordless 30-day magic-link portal, so an external approver never creates an account. Threaded internal and external comments and reminders attach to that flow.
What you actually configure before the first post
The README gives deployment options rather than a command sequence. It lists a one-click deploy on Heroku, Render or Railway, a Docker deployment on your own VPS, and a local run. No Dockerfile contents, compose service names or environment variable names appear in the supplied material, so the concrete configuration keys cannot be quoted here without inventing them.
What the material does establish is the prerequisite that dominates setup time: your own developer credentials for every platform you connect. Each network requires an application registered in its developer console, with redirect URIs pointing at your instance and the scopes the integration needs. That work scales with the number of platforms, not with the number of clients, but it is front-loaded and it is the step that decides whether the project is viable for you. The README notes that tokens and credentials are stored encrypted, and that Google SSO and Sentry are supported. It also states that 2FA via TOTP is on the roadmap, which means it is not available today.
The maintenance surface is the real cost
Twelve integrations with first-party APIs means twelve sets of deprecations, version bumps, scope changes and review processes arriving on their own schedule. An aggregator exists precisely to absorb that work, and choosing BrightBean Studio means taking it back. Nothing in the README suggests a compatibility layer that would soften a platform-side breaking change. The automatic retries and rate-limit tracking handle transient failures, not a redesigned endpoint.
The project is also young in release terms. No releases were retrieved, the default branch is main, and the CI badge is the only build signal in the README. The roadmap item for TOTP means administrators currently have password and Google SSO as the account protection story, which is a consideration if the instance is reachable from the public internet and holds credentials for a dozen client accounts.
There is a second boundary worth stating. The README positions BrightBean Studio against Buffer, Sendible and SocialPilot, but those products are general-purpose schedulers. If your publishing is concentrated on one network, the multi-platform dashboard is overhead you are paying for in setup and maintenance without using it.
Where an aggregator-based tool still wins
Buffer is the obvious comparison, and the difference is not features but who holds the API relationship. Buffer maintains its own approved applications with each network and you authorise it once. You never open a developer console, never rotate a client secret, and never learn that a platform changed its review requirements. BrightBean Studio inverts that: you register the apps, you hold the credentials, and the README frames this as no vendor lock-in and no third party between you and your data.
That inversion is the whole decision. If your constraint is engineering time, an aggregator-based tool is cheaper even at a higher subscription price, because the subscription buys the maintenance you would otherwise do. If your constraint is per-seat cost at agency scale, or a policy requirement that client data and tokens stay on infrastructure you control, BrightBean Studio's approach is the one that satisfies it. The README's claim that all features are available to every user also removes a class of frustration, since approval workflows and the client portal are not behind a higher tier.
Licence and the upgrade path
BrightBean Studio is AGPL-3.0. For an agency running a private instance for internal and client work, the practical effect is that modifications you distribute or expose over a network carry source-availability obligations. The README markets the project as white-label friendly, with per-workspace branding for logo and colours, and that is where the licence deserves attention: rebranding a hosted instance for clients is a different situation from modifying the code and offering it as a service. This is not legal advice, and the specific boundary depends on what you change and how you expose it.
On upgrades, the material supports one observation and little else. The repository is active, with a last push in August 2026, and no releases were retrieved, so there is no tagged version history to pin against. Without release tags, an upgrade means tracking main or a commit, and there is no published migration or breaking-change policy in the supplied README. The 14-day reversible org-deletion grace period is the only data-safety mechanism mentioned. Anyone planning a production deployment should confirm how database migrations are shipped and whether a stable branch exists before treating upgrades as routine.
Editorial conclusion
Adopt BrightBean Studio if your agency or in-house team already runs Django or Docker workloads and you are willing to register your own developer apps with each platform you publish to. Do not adopt it if you need a vendor to hold the API keys, if you publish only to one network, or if you cannot absorb the maintenance that comes with twelve integrations. Before committing, verify that every platform on your list has a working publish path in the current code, that your host can run the background workers the publishing engine needs, and that AGPL-3.0 fits how you intend to distribute any modified version.
Community notes