Three Ways to Deploy AI in Community Platforms (and Why Choice Matters)

Every major community platform is racing to bolt AI onto its feature set, and most of them are doing it the same way: pick a model, hardcode an API, ship a chatbot, write a blog post, move on. The result is that thousands of communities with wildly different needs and wildly different threat models are all funneled into the same narrow integration, locked to one provider and one set of terms of service. Take it or leave it.

This is a problem that the software industry has solved before. We solved it for databases and we solved it for hosting, and we solved it for authentication. The principle is always the same: the platform that gives its operators meaningful choices about infrastructure will outlast the platform that makes those choices on their behalf. And yet, when it comes to AI, almost nobody is building for optionality.

Discourse is trying to do something different.

We think about AI deployment in three distinct paths...

Bring your own API key (and why it's the right default)

The most straightforward deployment is what you'd expect: bring your own API key from OpenAI, Anthropic, Google, or any of the major cloud providers. Plug it into your Discourse instance. The platform's AI features light up. You're running inference through a provider you chose, under terms you agreed to, with billing you control.

This is the path that works for the vast majority of communities. It's the path that works for the marketing team at a mid-size SaaS company running a support forum, for the developer relations team at a startup that needs automated topic summarization, for the gaming community with fifty thousand members that wants better search, and for the open-source project that wants to surface answers from years of archived threads. These operators don't want to think about model architecture. They want AI features that work, and they want to pick a vendor they trust.

Larry Wall, the creator of Perl, used to talk about making easy things easy and hard things possible. The API key path makes the easy thing easy. You don't need a machine learning engineer or a DevOps team. You need an API key and about ten minutes.

But boring has an advantage that gets overlooked in most conversations about AI integration. When you bring your own API key, you can switch providers. If OpenAI changes its pricing, you move to Anthropic. If Google launches a model that handles your community's language mix better, you move to Google. The switching cost is approximately zero, because the abstraction layer sits in Discourse, not in the provider. This is the same principle that made S3-compatible storage a de facto standard: once you decouple the application from the specific backend, competition works in your favor instead of against you.

Managed AI

The second deployment option targets operators who don't want to manage API keys at all. If you're hosting your Discourse instance through Discourse's own hosting, AI comes pre-configured. The model is already there and the integration is already live. You, the community operator, interact with AI features without ever touching an API dashboard.

The entire arc of cloud computing, from raw EC2 instances to fully managed serverless functions, is a story about operators gradually and rationally choosing to hand off complexity to specialists. Nobody mocks a company for using managed Postgres instead of tuning shared_buffers by hand. The community platform space should follow the same logic.

By offering a managed AI layer, Discourse takes on the work of evaluating models, handling failover, and keeping the integration current as models change. That's a genuine service, and for the right operator, it's worth more than any amount of configurability. The VP of Community at a hundred-person company does not want to develop opinions about context window sizes. She wants her community's AI features to work on Monday morning, and she wants someone else to make sure they keep working.

There's a detail here that's worth making explicit, because it speaks to a concern that most "managed AI" offerings gloss over entirely. Discourse's managed AI runs on open-weight models hosted on Discourse's own infrastructure. Your community's data doesn't get routed through a third-party AI provider's API. It stays within the same environment where your Discourse instance already lives. This means the managed path doesn't just remove operational complexity — it also sidesteps the data residency and third-party dependency questions that make a lot of operators nervous about managed AI in the first place. You get the convenience of a fully managed service with many of the sovereignty benefits that would normally require self-hosting.

The managed path also solves a coordination problem that's easy to miss: when AI is pre-configured and bundled with hosting, it becomes part of the platform's baseline experience rather than an optional add-on that some instances have and others don't. Which means Discourse can build features that assume AI is present, which leads to deeper integration than you'd get if every AI feature had to gracefully degrade for instances that hadn't gotten around to setting up their API keys yet.

Self-hosted models, and why sovereignty still matters

The third option: run whatever model you want, on your own hardware, whether that's bare metal in your own data center or GPU instances in whatever cloud you prefer, and point Discourse at it.

This is the path that matters for regulated industries and communities operating under strict data residency requirements, for organizations where the phrase "we send our users' data to a third-party API" would end a procurement conversation before it started. It's also the path that matters for the technically ambitious, for the team that wants to fine-tune a model on their community's specific corpus, or run a smaller specialized model that outperforms a general-purpose giant on their particular use case.

There's a common misconception that self-hosted AI is only relevant for enterprises and hobbyist tinkerers, with nothing in between. That assumption is about two years out of date. Efficient open-weight models have proliferated and quantization evolved, while serving frameworks like vLLM and llama.cpp have matured to the point where self-hosted inference is genuinely practical for a much wider range of organizations than most people realize. A mid-size tech company with an existing Kubernetes cluster can add model serving without a massive infrastructure overhaul. The difficulty curve has flattened dramatically.

What Discourse is doing here echoes a pattern from an earlier era of open-source infrastructure. In the early 2000s, the LAMP stack became dominant partly because each layer was independently replaceable. You could swap MySQL for Postgres, or swap Apache for Nginx. The stack's power came from its seams, from the clean boundaries between components that let operators make different choices at each layer without blowing up the whole system. Discourse's AI architecture follows the same principle: the AI layer is a module with a clean interface, and what sits behind that interface is the operator's decision.

Why the architecture matters more than any individual path

Why support three ways of doing the same thing?

Simple answer: they aren't the same thing.

They represent fundamentally different trust models, different cost structures, different compliance postures, and different operational philosophies. A community platform that serves only one of these models is leaving entire categories of potential operators on the table.

Communities are not fungible. A pharmaceutical company's internal knowledge base has different requirements than an open-source project's contributor forum, which has different requirements than a consumer brand's customer community. Pretending otherwise, pretending that one AI deployment model fits all of these use cases, is the kind of false simplification that ships fast and ages badly.

The communities that will thrive over the next decade are the ones whose platforms treat AI as infrastructure rather than as a feature. Infrastructure is something you configure and something you can swap out when better options emerge. A feature is something you get or you don't. Discourse's three-path approach bets that community operators are sophisticated enough to appreciate the difference, and that the market will reward the platform that respects their intelligence enough to give them real choices.

That bet has paid off in every other layer of the stack.

There's no reason it won't pay off here.