How to Self-Host Crowd.dev in 2026

Why Teams Self-Host Crowd.dev

Crowd.dev (Apache-2.0, ~3.4K stars, now hosted under the Linux Foundation) is a community CRM: a unified view of the people in your Discord, Slack, GitHub, forum, and social channels, with activity scoring, segmentation, and integrations into your go-to-market stack. It overlaps with Orbit, Common Room, and Savannah CRM.

DevRel and developer-marketing teams self-host Crowd.dev when:

• The organization requires community data (identities, messages, PII) to stay in-house
• Costs of seat-based community CRMs are outpacing the value
• Integrations need custom fields or pipelines that managed tools do not expose
• The team already runs a data platform and wants to own the identity-resolution logic

What Crowd.dev Is and Is Not

Crowd.dev is a community CRM: identities, organizations, activities, and segments, glued together with integrations that pull from developer platforms. It is not a community platform — it does not host your Discord or forum. Think of it as the Salesforce of community operations, not the Discourse.

The architecture is a TypeScript/Vue front end, Node backend services, PostgreSQL as the system of record, Redis for queues, and a set of workers that pull data from each integration. Search and matching rely on an OpenSearch/Elastic-compatible index.

Core Dependencies and Architecture

Expect to run or provide:

• PostgreSQL 14+ — primary store for members, organizations, activities
• Redis — job queue and caching
• OpenSearch or Elasticsearch — member search and segmentation
• Object storage — avatars, attachments, exports
• Multiple worker services — per-integration ingestion, enrichment, and scoring

Minimum practical footprint for a small community (under 50K members, 3–5 integrations): 4 vCPU / 8 GB RAM for the app tier, a dedicated Postgres instance, and a small OpenSearch node. Budget more memory for OpenSearch as the member base grows.

Deployment Flow

The fastest path is the official Docker Compose stack:

git clone https://github.com/CrowdDotDev/crowd.dev
cd crowd.dev/scripts
cp ../.env.dist.local ../.env
# edit secrets, Postgres password, OAuth credentials
./cli up

This brings up the frontend, API, background workers, Postgres, Redis, and OpenSearch. For production:

1. Move Postgres, Redis, and OpenSearch to managed services or dedicated VMs
2. Run the API and workers as separate container groups so workers can scale independently
3. Put the frontend behind a reverse proxy with TLS and SSO
4. Configure object storage (S3-compatible) for exports and avatars

The workers are the noisy neighbors here. Large Discord or GitHub backfills can saturate CPU and hit rate limits, so isolate them from the user-facing API.

Ingestion Sources and CRM Hygiene

Crowd.dev ships integrations for GitHub, Discord, Slack, Discourse, Reddit, Stack Overflow, LinkedIn, Twitter/X, and email. Each integration behaves a little differently:

• GitHub pulls issues, PRs, discussions, and stars via the App. Token scope matters — narrow scopes miss private repo activity.
• Discord requires a bot with message intents. Expect Discord to throttle aggressive backfills.
• Slack uses an app with read scopes. Historical backfill depth depends on plan retention.
• Discourse ingests via API token; categories can be filtered at import.

Member identities are resolved by merging records across platforms — a GitHub login, Discord handle, and email can collapse into one community member. The matching rules are tunable, but early on you will hit duplicates and false merges. Plan time to curate the first few thousand members manually.

Backfills, Syncs, and Data Quality Issues

Three gotchas repeat across deployments:

Backfill windows. Some integrations (notably chat platforms) expose only a limited history. A freshly self-hosted Crowd.dev will look sparse for weeks until it accumulates live activity. Do not benchmark against Orbit's seeded data on day one.

Identity drift. Members change GitHub usernames, leave Discord servers, and create new email aliases. Schedule a monthly review of unmerged duplicates and flagged low-confidence merges.

Rate limits. GitHub, Discord, and LinkedIn all apply per-app rate limits that are easy to hit during backfill. Stagger integration enablement rather than turning them all on at once.

Export your segments and activities periodically so that, if you ever need to migrate, you are not locked into the current schema.

Security and Ongoing Operations

• Secrets: OAuth credentials for every integration live in the environment; rotate them on team changes.
• Access control: front the app with SSO — Crowd.dev supports OIDC-style providers, and a community CRM holds enough PII to warrant it.
• Backups: nightly logical backups of Postgres, plus periodic snapshots of the OpenSearch index; the index is expensive to rebuild but not authoritative, so Postgres is the must-have.
• Upgrades: pin image tags and stage upgrades — schema migrations are non-trivial when member counts climb.

When to Use It Versus Simpler Community Tooling

If your entire community lives on Discord, a bot plus a spreadsheet will outperform a self-hosted CRM for months. Crowd.dev starts paying for itself when you operate across three or more platforms, need to report on community ROI to leadership, or want to trigger workflows (e.g., "top contributor hit a milestone") from unified activity.

For a broader category view, see alternatives to Orbit and open source community platforms.