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.

Choosing some options will additionally add some data to the @graph part of the configuration. This data can be modified if necessary. For example, when enabling an e-mail server, you will need to modify the added data in the configuration to correctly specify how to connect to that server.

This version of the tool makes configurations for servers running CSS v6.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.

Do not switch between WAC and ACP on an existing server if its data was previously was configured with the other system.

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.

Which methods can be used to be notified of changes to resources. These are based on the latest Solid Notifications specification.

"Legacy WebSockets" is an implementation of the deprecated Solid WebSockets API 0.1 and allows users to receive notifications for resources they do not have access to.

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.

These are additional parameters that can be used to fine-tune the server customization. Enabling any of these will add a new entry in the generated configuration, which you can use to update the necessary values in the overrideParameters block.

These options are only relevant for specific use cases. If you are not sure, you can safely leave them all disabled and the default values will be used.

The options below are just some of the parameters that can be customized, chosen based on what might be useful for people wanting to configure their server. If there is another value that you want to customize, you can open an issue in the repository, and we will have a look if it is something that can easily be added.

How long a Notification subscription is allowed to exist before it is automatically removed by the server, in minutes. Keeping track of all notification subscriptions forever can create an extra load on the server, see the usage documentation for more information.

This needs to be set for every supported Notification channel type.

The locking expiration timeout determines how long until an inactive request gets closed by the server. Increasing this value can be useful if people try to make large requests on unstable internet connections.

Determines which resource to return when a container is being read. By default, if someone browses to a container they will instead see the index.html resource in that container, allowing you to provide users with a nicer result.

This can be customized, both in the name of the resource to choose (default: index.html), and in the accept header situations where this should be done (default: text/html).

To completely disable this behaviour, configure the media range to be an empty string.

The path to the folder that contains the templates that are used to instantiate a new pod. The path is relative to where the Node.js process is executed from, or, if it starts with @css:, relative to the install location of CSS. HandleBars is used to interpret the templates.

The WebID is always expected to be in profile/card#me. The folder is expected to have separate folders to differentiate between the chosen authorization systems, see the original templates for an example.

Allows you to modify the OIDC settings of the server. This will put the entire OIDC configuration object in the configuration JSON as there is no way to split it up. To modify how long OIDC-related tokens are valid you will want to edit the values in the ttl block, in seconds.

To find an explanation of all fields, see the relevant documentation.

Generated config