Own DSW Instance#


For production use, we should consult deployment and other operations with the sysadmin or contact the DSW Team for professional services.

The following instructions are intended only for local deployment and trying it out. It does not include any safety measures that are required for production deployment and are handled differently based on specific requirements and deployment sites (e.g., using HTTPS, enabled websockets, backups, metrics-gathering, and many others).

Deployment with Docker#

The simplest way is to use Docker Compose. Requirements are just to have Docker installed, privileges for current users, and the Docker daemon started. At least basic knowledge of Docker is required.

  1. Clone the DSW Deployment Example repository

  2. Check config files (described in Configuration)

  3. Run the DSW with Docker compose docker-compose up -d

  4. After starting up, we will be able to open the Wizard in our browser on http://localhost:8080

  5. We can use docker-compose logs to see the logs and docker-compose down to stop all the services


It is important to use latest patch version, we should monitor the documentation or join the community Slack if new hotfix releases are available.

Deployment without Docker#

It is highly recommended using Docker. However, we can compile and run everything directly on our machine. Nevertheless, an additional expertise in programming and building/running Elm, Haskell, Python, and others is required.

The related code and instructions are available:

Default Users#

Initially, migrations will fill the database with predefined data needed including three users, all with password - password:

We can use those accounts for testing or initially make our own admin account and then delete them.


Having a public instance with default accounts is a security risk. We should delete or change default accounts (mainly Albert Einstein) if our DSW instance is public as soon as possible.


Do not use UIDs below 10000 as that might introduce a security risk.

DSW Registry#

When we have our own self-hosted instance, it is essential to register within the DSW Registry. It is a source of shared knowledge models, document templates, and locales that can support our deployment. The registry is also integrated inside the DSW. Therefore, we can easily pull new versions from the DSW. The registration can be done either directly in our DSW instance in Settings or via the DSW Registry website.

Initial Knowledge Model, Document Templates, and Locales#

When we have a fresh installation, there are just the default users and no knowledge models or document templates. We are free to create them from scratch if we want. Another option is to import existing KM and document templates from the DSW Registry.

In the DSW Registry, we can find the core knowledge model for general data stewardship and a couple of document templates, such as Horizon Europe and locales! Another option is to import it from a file if we have any (according to usage).

Database Backups#

If we want to regularly backup our database (and we should!), all we need to do is to set up a cronjob that backups PostgreSQL database (e.g., using pg_dump utility) as well S3 storage.

Deployment Requirements#

The following requirements were estimated using limiting Docker resources provided to containers.





128 MB

512 MB


16 MB

64 MB

Document Worker

240 MB

1024 MB


240 MB

448 MB


624 MB

2048 MB

As for the CPU, there are no long-running tasks that would require excessive CPU consumption. Limiting CPU resources can only make some operations slightly longer (e.g., importing a knowledge model or generating a document). A number of CPUs/cores will then affect performance for concurrent users/actions. Memory consumption is affected by the size of the content (as some content is being cached for speed optimizations).

Memory used by document workers might be affected by the size of the document template (and assets) for generating a document. Recommended memory in the table above is approximated for a long-term run (without restarts) with a significant amount of content. It also minimizes the need for garbage collection techniques that may slow down the server component.


Real requirements should be aligned with the intended use (number of concurrent users, number of users in total, size of document templates, etc.). The minimal requirements are sufficient for single-user deployment and recommended requirements should handle tens of concurrent users.