Scoold: a Stack Overflow style Q&A server that keeps its data in Para

The problem Scoold solves, and the team it assumes you have

Internal questions repeat. Someone asks how a deploy rollback works, gets an answer in a chat thread, and six months later the same question appears again with no searchable record. Scoold's answer is a conventional Q&A surface: questions, answers, comments, votes, reputation, badges, full-text search, and Spaces, which the README describes as "groups of isolated questions and users". That is the whole pitch, and it is a reasonable one for engineering and support teams that already think in Stack Overflow terms.

The assumption underneath matters more than the feature list. Scoold is a client application, and the README is explicit that "almost every request to Scoold produces at least one request to Para as well". So adopting Scoold means adopting two services, two deployment targets, and a network path between them. A team that wants one container and a SQLite file is not the audience here. A team that already runs a JVM service and a database, and is comfortable wiring a second internal HTTP dependency, is.

Para is the database, the search index and the tenant boundary

The mechanism is worth stating plainly because it explains most of Scoold's behaviour. Para is a separate server, and the README describes it as multi-tenant, storing data in isolated environments called apps. Each app environment "has its own database table and search index". When a user posts a question, Scoold issues a create request to Para at POST /v1/questions. Reads, votes and searches follow the same pattern.

That gives you a few concrete properties. Scoold itself is stateless enough that several instances can point at the same Para app and share data, which the README calls out as a cluster arrangement. One Para server can power multiple Scoold sites through different apps, and Para can be hosted on a private network as long as Scoold can reach it over HTTP(S). The database choice is Para's, not Scoold's, so the "database-agnostic" claim in the feature list really means "whatever Para supports".

The cost is that Para is a hard dependency on the request path. If Para is slow or unreachable, Scoold has no local store to fall back on. The README does not describe a degraded mode, a local cache of question content, or a queue that buffers writes. It mentions a distributed object cache as a feature, but the material does not say whether that cache sits in Scoold or Para or how it behaves during a Para outage. Treat that as something to confirm in the documentation before you plan for failure.

Running it: a Spring Boot JAR in front of a Para endpoint

Scoold is a Spring Boot project that builds to a single JAR, and the README points to a Docker image at erudikaltd/scoold. The deployment shape it implies is: start Para, create an app inside it, then start Scoold configured with that app's credentials and the Para base URL. The README does not print the configuration keys in the excerpt available here, so the exact property names are not something to guess at; they are in the documentation site under scoold.com/documentation.

What the README does confirm about the runtime surface: Scoold is a client of Para's REST API, the API is defined with OpenAPI 3.0, and authentication options in the open-source build include LDAP, mutual TLS, and social login through Facebook, Google, GitHub, LinkedIn, Microsoft, Slack, Amazon and Twitter, with Gravatar support. Data import from Stack Overflow for Teams is listed as a feature, which is the migration path most teams will care about first.

A practical ordering for a first deployment: bring up Para and confirm you can hit its API directly, create the app environment, then start Scoold against it and check that a question created in the UI appears as a Para object. If that second step fails, the problem is in the Scoold-to-Para connection, not in Scoold's own code, and knowing that saves time.

Where the open-source build stops and Pro begins

This is the part that decides whether Scoold fits, and the README is unusually direct about it. The open-source feature list includes the Q&A core, Spaces, webhooks with signature signing, Zapier integration, email notifications for replies and comments, backup and restore, custom badges, and i18n with RTL support. The Scoold Pro list includes SAML authentication, SCIM 2.0 user provisioning, file uploads to local storage or S3 or Azure Blob, mentions with notifications, account suspensions, anonymous posts, unlimited spaces, multiple admins, multiple identity domains, sticky posts, email digests, and the Slack, Mattermost and Microsoft Teams integrations.

Read that split carefully, because several items sound like basics. If your organisation authenticates through SAML, the open-source build as described here does not cover it. If you need to attach a screenshot to a question, file uploads are on the Pro side. If you want a Slack bridge, same. The README also notes that issues related to Scoold Pro go to a separate repository, Erudika/scoold-pro, which is a hint about how the two codebases are maintained.

One more thing worth noting without reading it as a value judgement: the README markets Pro aggressively, including a line asking whether you are "still paying per seat in 2026" and describing flat pricing with a perpetual licence. That is vendor copy, not a technical claim, and it does not change what the Apache-2.0 code in this repository does.

The limitation that will bite first: two services, one failure domain

The architecture that makes Scoold small also makes it fragile in a specific way. Every user action crosses a process boundary. Latency adds up per request, and Para becomes a single point of failure for the whole site. The README lists deployment targets freely (Heroku, DigitalOcean, AWS, Azure, any VPS) and says both services can run on one machine or on separate networks, but it does not describe health checking, retry policy, or what the UI shows when Para returns errors.

There is a second, quieter limitation. Because Para owns the schema, search index and tenant isolation, tuning Scoold for a large corpus is really tuning Para. The README says Para can be configured to store data in any of the popular databases and links to its own database integrations page. That is where capacity planning lives. Anyone evaluating Scoold on the assumption that they can swap the storage engine from inside Scoold will be looking in the wrong repository.

And a third: the frontend is deliberately small. The README describes "minimal frontend JS code based on jQuery" with Materialize CSS. That is a maintenance choice, not a defect, but it means teams expecting a modern component framework to extend will be writing jQuery plugins against server-rendered pages.

What you would use instead, and how the approach differs

The obvious alternative is Discourse, which is also self-hostable and open source, but it is a discussion forum rather than a Q&A system. The difference is structural, not cosmetic. Discourse models topics and replies with a chronological reading order; Scoold models questions with accepted answers, votes and reputation, and its README describes suggestions for similar questions and hints for duplicate posts. If your team's problem is "we need a searchable knowledge base where the best answer rises", that is Scoold's shape. If your problem is "we need ongoing discussion threads with categories and mailing-list behaviour", Discourse fits better and does not require a second backend service.

A second option is to stay on the hosted Stack Overflow for Teams and not run anything. Scoold's counter is the import feature: data can be brought over from Stack Overflow for Teams, which means the migration is at least contemplated by the project. The trade is control and cost model against operational work.

A third, less obvious option is a wiki. Scoold is question-shaped by design, and the README lists "Wiki-style answers" as a Pro feature, which tells you the open-source build is not trying to be one.

Maintenance, licensing and what to check before you commit

Scoold is Apache-2.0, which permits commercial use, modification and redistribution under the terms of that licence; the usual obligations around notices and attribution apply, and this is not legal advice, so read the LICENSE file and your own counsel's view. The important licensing question is not Scoold's, it is the boundary with Scoold Pro. The README separates the two feature sets and routes Pro issues to a different repository, so the practical risk is adopting an open-source feature that later moves behind the paid line, or assuming a Pro capability is present because it appears in the same README.

On maintenance, the release cadence visible in the repository metadata is brisk: 1.70.1 on 2026-08-27, 1.70.0 two weeks earlier, 1.69.3 in July. Frequent patch releases are good for fixes and annoying for operators, because each one is a new JAR or image to roll out, and a rolling upgrade means Scoold instances briefly running against the same Para app at different versions. The README does not describe version compatibility guarantees between Scoold releases and Para releases, and that is the first thing to verify: pin both, and find out from the documentation whether a Scoold upgrade can require a Para upgrade.

The second thing to verify is the backup story end to end. The README lists backup and restore as a Scoold feature, but the data lives in Para, so a restore that only covers Scoold is not a restore. Test it against the Para database and search index you actually run, not the one in the quickstart.

Editorial conclusion

Adopt Scoold if you want a small Spring Boot service that gives a team Stack Overflow style questions, voting, badges and Spaces, and you are willing to run a Para server next to it, because Scoold stores nothing on its own. Do not adopt it if you need SAML, SCIM provisioning, file uploads or Slack and Teams integrations out of the box; those are listed as Scoold Pro features, and the repository README does not describe them as available in this codebase. Before committing, verify two things against the documentation: which Para database integration you will run in production, and whether your identity provider can be reached through the LDAP or social login paths that the open-source README lists.

Official sources

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