Community Solid Server configuration generator

This tool can be used to generate configurations for the Community Solid Server. More information about the configurations can be found in the CSS config folder and in the relevant tutorials. There is a tutorial specifically about customizing configurations if you want to customize your configuration even more afterwards.

Select the options you want from your server. The corresponding configuration can be found at the bottom. This configuration can then be used to start the server using the -c my-config.json CLI parameter.

This version of the tool makes configurations for servers running CSS v5.x.

All options related to where data is stored.

How internal data should be stored, such as account data. Data stored in memory will be lost on server restart.

How the data should be stored on the server. In-memory will cause the data to be lost when the server restarts. File options can use the --rootFilePath/-f CLI parameter to choose the root data folder to use, which defaults to the current folder. SPARQL options require the --sparqlEndpoint/-s CLI parameter to be set.

Which system to use to create locks. Locks are used to prevent simultaneous write operations on the same resource. Disabling this can cause data corruption. In-memory locking is insufficient if multiple workers threads are used.

Features related to the security of the server.

Determines if the server should be started for HTTP or HTTPS. If HTTPS is chosen, CLI parameters --httpsKey and --httpsCert need to be provided.

The authorization system to restrict who can access resources.

Disabling this allows everyone to access and modify all resources on the server.

Everything related to registering and creating new pods on the server.

Allow users to register new accounts and pods on the server.

Configure an e-mail server to be used when users forgot their password. This will add a new entry to the configuration JSON that needs to be updated with the credentials of your e-mail server.

How URLs for new pods should be created, appending the name to the base URL as a suffix, or using it as a subdomain.

Miscellaneous features not related to a specific category.

Adds support for the deprecated Solid WebSockets API 0.1. This allows users to be notified when resources change, without requiring authentication.

Authorization is not required, meaning everyone can see when private resources are updated.

Makes the root of the server accessible for reading and writing data. Enabling this will create the relevant authorization resources in the root that allow this.

These authorization resources provide full access to everyone so make sure to immediately update these. They will also not disappear after stopping the server and need to be deleted manually afterwards if you use a file system as backend.

Requires a setup procedure to occur after starting the server. This can be used to create a pod immediately on the server.

Advanced features. You should not change these options unless you are sure what they do.

Verifies that someone is the owner of an external WebID if they try to register an account with it. Disabling this means this server should not be trusted for authentication.

Use the chosen authorization method for the account-related APIs such as registration. This can be used to only allow authorized requests of specific WebIDs to register accounts. If enabled, the necessary authorization resources will be created in the /.well-known/ and /idp/ containers providing full access to everyone, so make sure to update these with the correct values.

Convert all requests to a static page in case HTML is requested. This is needed when you want to add a UI such as Mashlib or Penny. You will have to update the configuration file with the correct values.

Generated config