Superdesk is a newsroom pipeline from story to distribution

The scope is the whole newsroom, not a piece of it

The repository description names five stages, and the README expands them into a single sentence: news creation, production, curation, distribution and publishing. That is the differentiator. A team that only needs a content API and a front end would find Superdesk oversized, but a newsroom that currently stitches together a CMS, a planning tool, an ingest script and a distributor gets all of that in one system. The project is developed and maintained by Sourcefabric with the stated purpose of making the best possible software for journalism, and the README says it is scaleable to suit news organisations of any size. The intended user is an editorial organisation with a newsroom workflow, and the topic tags on the repository say curation, news-creation and superdesk. Starting the whole stack in Docker is one command, and the README gives it as the quickest route to a running instance:

$ docker compose up -d

Server and client are deliberately separate applications

The architecture is split in two and the README is explicit about it. The Superdesk server provides the API to process all client requests, and the client provides the user interface, with server and client being separate applications using different technologies. The server side is Python, and the client is a JavaScript application; the repository root holds a client/ directory and a server/ directory, and the client configuration is documented in the separate superdesk-client-core repository rather than here. The Docker compose file makes the split concrete, with a superdesk-server service and a superdesk-client service as two containers, and the client built with a SUPERDESK_URL build argument pointing at the server API. For anyone extending the product, the client side work happens in a different repository, which is the first thing to understand before planning an extension.

Docker Compose is the quick path, with two commands to seed it

The compose file is the fastest route to a running instance, and the first run needs two extra steps because the databases are empty and there is no user to log in with. Initialising the data and creating the first administrator are two management commands, and the README notes that you can then log in with the admin:admin credentials:

# Initialize data
$ docker compose exec superdesk-server python manage.py app:initialize_data
# Create first admin user
$ docker compose exec superdesk-server python manage.py users:create -u admin -p admin -e admin@localhost --admin

The compose file also shows the backing services, with MongoDB on 27017, Redis on 8, and ElasticSearch pinned to 7.17.29 as a single-node discovery instance, all on a shared superdesk network, while the server service itself depends on redis, mongodb and elastic. The images for both the client and the server are published on Docker Hub under the sourcefabricoss organisation, so you can run the published images or build the same source locally.

The environment variables are the configuration surface

Everything about the server service is configured through environment variables, and the compose file is effectively the reference for them. The URLs come first, with SUPERDESK_URL pointing at the API, SUPERDESK_CLIENT_URL at the client and CONTENTAPI_URL at a separate content API path, and then there are four separate MongoDB URIs for the main database, the content API, the public API and a legal archive, plus a separate archived URI. ElasticSearch gets its own URL and an index name, Redis appears twice as the Celery broker and as the general Redis URL, and there is a DEFAULT_TIMEZONE set to Europe/Prague and a SECRET_KEY. One entry is worth reading twice, since it is a switch rather than a setting: DEMO_DATA=1 installs demo data, and the comment says to set it to 0 for a clean install. The compose file also points at further options in the Superdesk settings documentation.

Local development splits the client out of the container

Running the whole stack in Docker is fine for trying the product, but the README describes a different workflow for editing the client or extensions and seeing changes immediately, the server-in-Docker and client-native workflow documented in DEVSETUP.md. Its prerequisites are specific: Docker Desktop installed and running, Volta installed because the Node version is pinned through it, and sibling repositories cloned in the same parent directory, with superdesk-client-core and superdesk-planning required and superdesk-analytics and superdesk-publisher optional. The layout matters, and DEVSETUP.md carries a full layout diagram and the reasoning behind it. Once the prerequisites are in place the process is two steps, run the setup script and then open http://localhost:9000 and log in with admin and admin, with the script layer exposed as three commands for setup, up and down, the last of which stops the stack while preserving the data.

A manual install needs five services and a virtual environment

The manual path is documented in full and it is the one to read if you are not using containers. The requirements list is MongoDB, ElasticSearch 7 or newer, Redis, Python 3.12 and Node.js with npm, and on macOS the README suggests a single homebrew command to install mongodb, elasticsearch, redis, python3 and node. The installation steps clone the repository into a path of your choosing, then install the server requirements with pip3, initialize the data with a management command, create the first admin user, and start the server with honcho start. There is a separate prepopulate command for when you want sample data. The client side is npm install, npm run build and npx grunt server, and the result is on http://localhost:9000. The steps in full are:

path=~/superdesk
git clone https://github.com/superdesk/superdesk.git $path

# server
cd $path/server
pip3 install -r requirements.txt
python3 manage.py app:initialize_data
python3 manage.py users:create -u admin -p admin -e '[email protected]' --admin
honcho start
# if you need some data
python manage.py app:prepopulate

# client
cd $path/client
npm install
npm run build
npx grunt server

# open http://localhost:9000 in browser

The macOS note at the end is not optional: every one of those commands has to run inside a Python virtual environment created with pyvenv and activated with the activate script.

The compose file is also a description of the deployment shape

Reading the compose file tells you more about how Superdesk is meant to run than the prose does. The server container joins two networks, superdesk and superdesk-newsroom, which suggests a topology where the publishing side and the newsroom side are separated at the network level, and the client service is built from the client/ directory with its own Dockerfile and build arguments for the API URL and a WebSocket URL at ws://localhost:8080/ws. The WebSocket endpoint is the detail worth noting for anyone planning real-time newsroom updates. The images for both are published on Docker Hub under the sourcefabricoss organisation, and the compose file builds locally from the same source, so a local build and a published image are meant to be interchangeable. There is also a separate docker-compose.dev.yml for development, which sits alongside a Docker-based dev workflow rather than replacing it.

AGPL-3.0, a develop branch, and release tags every few months

The licensing is the first thing to read before evaluating a platform you intend to run and extend. The README states that Superdesk is available under the AGPL version 3 open source licence, and the LICENSE file sits at the root alongside a SECURITY.md, a CHANGELOG.md and a CONTRIBUTING.md. That is a strong copyleft, and for an organisation running its own newsroom the practical question is different from the one a developer embedding a library faces, but the obligation to offer source for modified versions that are put into use over a network still applies. On the release side, the recent tags are v3.5 on 2026-07-14, v3.3 on 2026-02-23 and v3.2 on 2026-01-27, the default branch is develop rather than main, and the last push to the repository was on 2026-10-20. Questions and general feedback go to the Sourcefabric forum, while the issue tracker is for bug reports and feature requests only.

Editorial conclusion

Superdesk suits a news organisation that wants an end-to-end editorial workflow, from ingest through curation to distribution and publishing, and that is prepared to run MongoDB, ElasticSearch, Redis and a Python service rather than a single application. It does not suit a team that needs a small content API or a headless CMS front end, since the product is a full newsroom system rather than a library or a service you embed. Before adopting, read DEVSETUP.md for the local development layout, note that the default branch is develop and the newest tagged release is v3.5 from 2026-07-14, and remember that the AGPL version 3 licence covers the platform you run as well as any modification you distribute.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. superdesk/superdesk on GitHub