Scoold: a self-hosted Stack Overflow clone for teams, with Para as the backend

Who Scoold is for, and the problem it removes

Scoold is a Q&A and knowledge sharing platform for teams, inspired by Stack Overflow. The README frames it as the way to share knowledge inside a team or organization, and the project history it gives is long: created in 2008, released in 2012 as a social network for schools, refactored and open-sourced in 2017. That history matters less than the shape of the product. It is a forum where a question gets answers, answers get voted, and reputation and badges accumulate around the people who write them.

The audience is a company or team that wants Stack Overflow style discussion without sending its internal questions to a third party. The README lists the features that make that concrete: Spaces (Teams) as groups of isolated questions and users, full-text search, email notifications for replies and comments, and an import path from Stack Overflow for Teams. The last one is the clearest signal of intent. Scoold is positioned as a place to move an existing corpus of internal Q&A into, not as a greenfield community you build from nothing.

It is not a general-purpose forum. There are no categories of the classic bulletin-board kind here; the unit is the question and its answers, plus Spaces when you need separation between groups. If your team's knowledge lives in long-form documents rather than question threads, a wiki is a better fit and Scoold will feel like the wrong container.

The Para split: why Scoold is two services, not one

The README is direct about this: Scoold is a client application of the Para backend server, and almost every request to Scoold produces at least one request to Para. Asking a question sends a create request to Para at POST /v1/questions. So the architecture has two moving parts, and the second one holds the data.

Para is a multi-tenant server that stores data in isolated environments called apps. Each app has its own database table and search index, and apps are independent of each other. That gives you a few deployment shapes. One or more Scoold instances can connect to the same Para app and share the data, which is how you would run a cluster. Alternatively, several separate Scoold sites can be powered by one Para backend using different apps. Scoold and Para can sit on the same machine or on different machines; Para must be reachable from Scoold over HTTP(S), and it can live on a private network.

The payoff is that all the storage and search work is delegated. Para supports several databases, and the README says Scoold is database-agnostic because of it. The cost is operational: your knowledge base now depends on two processes, and a Para outage takes Scoold down with it. The README also claims the split keeps the Scoold code base small enough to be learned quickly, even by junior developers. That is a reasonable claim for the application layer, but it does not reduce what you have to operate.

Installing Scoold with Docker and asking the first question

The repository ships a docker-compose.yml that starts both services. The Para container listens on 8080 and the Scoold container on 8000, and Scoold is told where Para lives through a Java system property.

services:
   para:
     image: erudikaltd/para:latest_stable
     ports:
       - "8080:8080"
   scoold:
     depends_on:
       - para
     image: erudikaltd/scoold:latest_stable
     ports:
       - "8000:8000"

The compose file binds two configuration files from the host: ./scoold-application.conf into the Scoold container and ./para-application.conf into both, so you need those files present before the stack will start cleanly. The Scoold environment sets JAVA_OPTS with -Dconfig.file=/scoold/application.conf, -Dscoold.autoinit.para_config_file=/scoold/para-application.conf and -Dscoold.para_endpoint=http://para:8080. That last property is the one that makes the two containers find each other inside the compose network, where the Para service is reachable by its service name.

docker compose up

After the containers come up, open http://localhost:8000 in a browser. The README points to a live demo at demo.scoold.com, and says that for admin access there you go to the demo login page and click "Continue with Demo Login". For your own instance, the configuration file is where you set up the connection details and authentication options. If you would rather not use Docker, the Dockerfile shows the alternative: the project builds with Maven into a single JAR (target/scoold-*.jar), and the runtime image copies it to scoold.jar and starts it with java $JAVA_OPTS -jar scoold.jar. The Dockerfile exposes port 8000 and honours a BOOT_SLEEP environment variable, which the compose file sets to 5 so Scoold waits before starting.

What the open source edition leaves to Scoold Pro

This is the limitation that decides most evaluations. The README splits features into two lists, and the second one is behind Scoold Pro, the paid version. SAML authentication, SCIM 2.0 user provisioning, file uploads to local storage or AWS S3 or Azure Blob, account suspensions, anonymous posts, multiple admins, mentions with notifications, and the Slack, Mattermost and Microsoft Teams integrations are all on the Pro side. So are unlimited spaces, sticky posts, a wiki-style answer format and email digests.

The open source build still covers a lot: full-text search, Spaces, voting and badges, custom badges with your own text and color, webhooks with signature signing, i18n with RTL support, LDAP authentication, social login across Facebook, Google, GitHub, LinkedIn, Microsoft, Slack, Amazon and Twitter, GFM markdown with tables and task lists, and syntax highlighting in posts. Mutual TLS is listed too. But if your organization's identity provider speaks SAML rather than LDAP or OAuth, the open source edition does not cover it, and that is a hard stop rather than a configuration detail.

The other limitation is structural rather than commercial. Because Scoold delegates storage to Para, any question about backups, replication or database choice is really a question about Para. The README lists backup and restore as a feature, but it does not describe the procedure, so you will need the documentation at scoold.com/documentation before you trust it with data you care about.

Scoold against Discourse and plain Stack Overflow for Teams

The obvious alternative is Discourse, and the difference is in the data model rather than the feature list. Discourse is built around topics in categories, with a linear reply stream; a thread is a conversation that happens to be organized. Scoold is built around questions with accepted and voted answers, and the README's feature list follows from that: reputation, badges, hints for duplicate posts, suggestions for similar questions. If your team asks the same configuration question every few months, the question model is the one that surfaces the previous answer. If your team discusses designs and decisions, a topic model fits better.

The other comparison is Stack Overflow for Teams, which Scoold explicitly offers an import path from. The difference there is hosting and control: Scoold is self-hosted, Apache-2.0 licensed, and deployable to Heroku, DigitalOcean, AWS, Azure or any VPS according to the README. You own the deployment and the data, and you also own the upgrades, the database behind Para, and the uptime. Stack Overflow for Teams removes that work and keeps the data with a vendor.

A third option worth naming is a plain wiki. It wins when the content is reference material that a few people maintain, and loses as soon as you want voting to tell you which answer is trustworthy. Scoold's whole value proposition assumes that signal matters to you.

Maintenance, licensing and what an upgrade actually costs

The repository is not archived and the last push was on 2026-08-27, the same day as the 1.70.1 release; 1.70.0 landed on 2026-08-13 and 1.69.3 on 2026-07-09. Releases arrive at a steady cadence, and the project states it is fully funded and supported by Erudika, an independent company. That matters for a self-hosted tool: there is a commercial entity behind it, and the same entity sells the Pro edition, so the open source build is not abandoned.

The licence is Apache-2.0, and the LICENSE file is in the repository root. Apache-2.0 covers the open source code; the README describes Scoold Pro separately as a premium version with flat pricing and a perpetual licence, and it directs Pro issues to the Erudika/scoold-pro repository. Where the boundary between the two falls for your use case is something to check against the pricing page rather than assume. Nothing here is legal advice, and if you plan to redistribute or embed Scoold in a product, read the licence text itself.

Upgrade cost is where the two-service design shows up again. Upgrading Scoold means pulling a new image tag; the compose file pins latest_stable, which moves under you, so a serious deployment should pin a version instead. Upgrading Para is a separate decision with a separate image, and the two have to stay compatible. The compose file also mounts paraData and paraLib volumes, and the Para container reads its configuration from /para/application.conf. Back up those volumes before you change either image, because that is where the state lives.

Editorial conclusion

Adopt Scoold if you want your team's questions to live in your own infrastructure and you accept running two services, Scoold plus Para, instead of one. Skip it if you need SAML, SCIM provisioning, file uploads or Slack and Teams integrations out of the box, since the README lists those under Scoold Pro, the paid version. Before committing, verify the two containers start and talk to each other with your own scoold-application.conf, confirm which database Para is pointed at, and check the Apache-2.0 LICENSE file for how the open source and Pro editions are separated.

Frequently asked questions

Official sources

1. Erudika/scoold on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases