BrightBean Studio: Open-Source Social Media Management Across 13 Platforms

What BrightBean Studio Is and Who It Is For

BrightBean Studio is an open-source social media management platform built on Django, designed for agencies and small-to-medium businesses that manage content across multiple client accounts. The README describes it as doing what Sendible, SocialPilot, and ContentStudio do, but with no per-seat, per-channel, or per-workspace limits and with self-hosting as a first-class deployment option.

The intended user is someone managing many client accounts under one roof who would rather own their social stack than pay the recurring SaaS fees these tools charge. Every feature is available to every user; the README states there is no paid tier, no feature gate, and no upsell.

A free hosted version is available at brightbean.xyz/studio. This runs the same codebase as the repository, with no setup required. Teams who want control over their data and infrastructure can self-host via Docker, or deploy with a one-click button to Heroku, Render, or Railway.

Platform Coverage and Direct API Integration

The platform list covers Facebook, Instagram (standard and direct), LinkedIn (personal and company), TikTok, YouTube, Pinterest, Threads, Bluesky, Google Business Profile, Mastodon, and DEV.to. Publishing support is available for all of them. Comment and DM support varies by platform: Facebook, Instagram, Threads, Bluesky, Mastodon, and YouTube support comments; Instagram, Facebook, and some others support DMs. Analytics (Insights) are available for most major platforms.

All integrations talk directly to the official first-party APIs using the operator's own developer credentials. The README is explicit that there is no aggregator middleman and no third party between the operator and their data. This is a meaningful architectural difference from tools that sit as a proxy in front of platform APIs, which can introduce rate-limit pooling and dependency on the aggregator's continued operation.

The direct-API approach has one practical consequence documented in the README: Instagram, Threads, Facebook, Pinterest, Google Business Profile, and DEV.to fetch attachment URLs server-side when publishing. This means the /media/ path must be publicly reachable from the internet when using local storage. The SERVE_MEDIA environment variable controls this, and the README documents that the files are served unauthenticated, which is a requirement of the publishing flow rather than a security oversight.

Deploying with Docker or One-Click on Heroku, Render, or Railway

The Docker deployment uses a docker-compose.yml that defines four services: a migration runner, the application server, a background worker, and a PostgreSQL database.

services:
  app:
    build: .
    volumes:
      - media_data:/app/media
    ports:
      - "8000:8000"
    env_file:
      - .env
    depends_on:
      migrate:
        condition: service_completed_successfully
    restart: unless-stopped
  worker:
    build: .
    command: python manage.py process_tasks

The worker process runs background tasks using django-background-tasks. The application runs on port 8000. Both the app and worker share the media_data volume so uploads are accessible to both.

For the one-click deploy buttons (Heroku, Render, Railway), the README lists the environment variables that must be set. Two are required and not auto-generated: ALLOWED_HOSTS (the app's domain name) and APP_URL (the full public URL). STORAGE_BACKEND must be set to `s3` for production deployments on Heroku, Render, or Railway, because those platforms have ephemeral filesystems. The README states that without S3, uploaded files are lost on every redeploy. The SECRET_KEY and ENCRYPTION_KEY_SALT are auto-generated by the deploy button.

Content Workflow: Composer, Calendar, Approval, and Client Portal

The content composer supports per-platform caption and media overrides, which allows a single piece of content to have different text or image crops for different platforms. It also includes version history, reusable templates, content categories, tags, and a Kanban idea board.

Scheduling uses a visual calendar with drag-and-drop. Recurring weekly posting slots can be defined per account, and named queues auto-assign posts to the next available slot. This covers the two main scheduling workflows: fixed-time publishing and queue-based publishing without specifying exact times.

Approval workflows have four configurable stages: none, optional, internal, and internal plus client. When client approval is required, the client accesses the post through a passwordless 30-day magic-link portal. The README describes this as allowing clients to approve or reject posts without creating an account. The approval flow includes threaded internal and external comments, reminders, and a full audit trail.

The white-label feature allows per-workspace branding (logo and colors), which makes it practical for agencies that want clients to see the agency's own brand rather than BrightBean's.

Social Inbox, Analytics, and the MCP API Integration

The unified social inbox aggregates comments, mentions, DMs, and reviews from all connected platforms into a single view, with sentiment analysis, assignment, threaded replies, and historical backfill. This consolidates what would otherwise require logging into each platform separately to monitor and respond.

Analytics pull from each platform's native API and present per-post and channel-level metrics: KPI cards, 7/30/90-day trend charts, and a sortable all-posts table for views, engagement, follower growth, reach, and watch time.

The requirements.txt includes the mcp Python package (version 1.0 to 2.0) and django-oauth-toolkit (3.0 to 4.0). The README in the requirements.txt comments describes an MCP endpoint at /api/v1/mcp/ using Streamable-HTTP transport, and an OAuth 2.1 Authorization Server for the MCP endpoint. This allows AI coding agents such as Claude Code, Codex, and OpenClaw to connect to BrightBean Studio's API using the OAuth DCR and authorization-code flow. Existing API key authentication continues to work alongside this.

How BrightBean Studio Compares to Buffer and Similar Tools

Buffer is the most widely known commercial alternative in this category. Buffer is a cloud-only SaaS; there is no self-hosted option. It charges per social account per month, which adds up quickly for agencies managing many client accounts. BrightBean Studio has no per-seat or per-channel limits, and the AGPL-3.0 licensed codebase can be deployed on infrastructure you control.

The trade-off is operational responsibility. A team using Buffer pays for reliability, support, and maintenance. A team self-hosting BrightBean Studio owns the infrastructure, the upgrades, and the incident response. The free hosted version at brightbean.xyz/studio removes the operational burden but re-introduces vendor dependency, since it is a service rather than infrastructure you control.

BrightBean Studio's feature list (approval workflows, client portal, MCP API, media library) is broader than what entry-level Buffer plans include, but the comparison is qualitative: the README does not make specific claims about Buffer's current feature set, and commercial tools change their offerings frequently.

Security, AGPL-3.0 Licence, and Maintenance Status

The README lists several security features: encrypted token and credential storage, Google SSO, Sentry integration for error monitoring, and a 14-day reversible org-deletion grace period. Two-factor authentication (TOTP) is on the roadmap but not yet implemented.

BrightBean Studio is licensed under AGPL-3.0. Like Beta9, the AGPL imposes a network use clause: any organisation that deploys a modified version of this software as a service and allows users to interact with it over a network must release the source of those modifications. An agency that self-hosts the unmodified software and uses it internally is not affected. A company that builds a white-labeled social media management product on top of BrightBean Studio and offers it to paying customers must open-source their modifications under AGPL.

The last push to the repository was on 2026-09-25. The repository has no GitHub releases, which means version selection for deployments requires pinning to a commit hash. A .github/ directory and a CI workflow (ci.yml) are present, indicating the project runs automated checks on commits.

Editorial conclusion

BrightBean Studio suits agencies and creators who manage many client accounts and want to avoid the per-seat or per-channel pricing of commercial tools. The AGPL-3.0 licence means any modified version deployed as a service must release its source, so teams that plan to customise and ship it as a hosted product for paying customers need to account for that obligation. Before going to production, set STORAGE_BACKEND=s3: the README warns that Heroku, Render, and Railway have ephemeral filesystems and that uploaded files are lost on redeploy without an external storage backend.

Frequently asked questions

Official sources

1. brightbeanxyz/brightbean-studio on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README