How Is Scoold Deployed and Can It Run On-Premises?
Yes. Scoold is designed for self-hosting and can run entirely on your own infrastructure — on-premises servers, private clouds, or any cloud provider you choose. According to Scoold's own product page, it ships as a Docker container, a JAR, or a native executable, and the project describes deployment as taking minutes. A managed option, Scoold Cloud, also exists if you'd rather not run the infrastructure yourself.
What "self-hosted" means for Scoold
Scoold is a Q&A platform, forum, and knowledge base for teams. Its core selling point is that you keep full ownership of your data: the application runs on infrastructure you control, so questions, answers, user accounts, and search indexes stay inside your environment rather than on a vendor's servers.
The product page frames this as "privacy-first" and "your data, your rules." That matters most for teams that handle internal documentation, customer support content, or anything subject to internal data-handling rules.
Deployment options
| Option | What it is | Best suited for |
|---|---|---|
| Docker container | Packaged image you run on your own host or orchestrator | Most teams; the page cites 5M+ Docker Hub downloads |
| JAR | Java application artifact you launch directly | Teams already running JVM services |
| Native executable | Standalone binary | Environments without a JVM or container runtime |
| Scoold Cloud | Managed hosting offered by the project | Teams that want Scoold without operating it |
The page also notes Scoold can be deployed "to any cloud provider," so the self-hosted path isn't limited to physical on-premises hardware — a private VPC or a single cloud VM both qualify.
What you need before deploying
The source material doesn't publish a detailed system-requirements list, so treat the following as the general shape of a self-hosted Java web application rather than a Scoold-specific spec:
- A host — a server, VM, or container platform you control.
- A runtime matching your chosen artifact — Docker for the container image, a JVM for the JAR, or nothing extra for the native executable.
- Persistent storage for the database and any uploaded content, so data survives restarts.
- Network and TLS configuration if the instance will be reachable by your team.
- Identity provider details if you plan to use SSO — Scoold supports LDAP, SAML 2.0, OAuth 2.0, and SCIM.
How to verify a deployment worked
The page doesn't document exact commands, but any self-hosted Scoold instance should let you confirm the same things:
- The service starts and stays up without crashing on restart.
- You can reach the web UI and create the first admin account.
- Full-text search returns results for a question you post.
- If SSO is configured, a test user from your directory can log in.
- Data persists — restart the container or process and confirm your test question is still there.
Common sticking points
- SSO is the usual friction point. LDAP, SAML, and OAuth2 each need correct callback URLs and attribute mappings; the page lists these as supported but doesn't walk through configuration.
- Backups are your responsibility. Scoold advertises "reliable backup & restore" with import/export, but on self-hosted infrastructure the schedule and storage are yours to manage.
- "Minutes to deploy" assumes prerequisites are ready. The claim on the page refers to the application itself, not to provisioning a database, DNS, or certificates.
Self-hosted vs. Scoold Cloud
Choose self-hosted if data residency, internal network isolation, or full control over upgrades is a hard requirement — and you have someone who can operate a container or JVM service.
Choose Scoold Cloud if you want the same platform without owning the runtime, and your data-handling rules permit a managed service.
The page mentions a free download and a demo, plus a premium version (Scoold Pro) with "no per-seat fees." It does not state pricing figures or whether any tier requires a paid license, so check the pricing page directly before committing.