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 v7.x.

All options related to how data is stored.

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.

The authorization system to restrict who can access resources.

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

If you have a running server and want to switch between authorization systems, you will also have to replace the relevant authorization resources as, for example, ACP can not interpret WAC authorization resources.

Enables support for the core Solid protocol. This can be disabled if you want a server that only handles OIDC and accounts.

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

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.

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

Everything related to account management. The two final options still enable account management, but disable certain features for users.

If this is enabled anyone will be able to create new pods on your 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.

Allows the server to generate the necessary tokens and interactions for an OIDC session. You need this if you want to use the server to log in to Solid applications.

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.

"All" includes all supported notification channels. This currently includes WebSockets, WebHooks and Streaming HTTP.

Determines what needs to happen with the root of the server.

The "Root pod" option creates a pod in the root with the email and password defined in the configuration. It is advised to immediately change this password.

The "Accessible root" option writes authorization resources to the root of the server, giving full access to everyone. It is advised to immediately update these after starting the server to prevent misuse. They will also not disappear after stopping the server and need to be deleted manually afterwards if you use a file system as backend.

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

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.

Several of these options allow you to provide a path to a file. This path is always relative to where the Node.js process is executed from, or, if it starts with @css:, relative to the install location of CSS.

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. HandleBars is used to interpret the templates.

The folder at the path location is expected to have separate folders to differentiate between the chosen authorization systems, see the original templates for an example.

The main HTML body that is used for all HTML pages generated by the server. See the original version to know what is expected.

The HTML page used when registering an email/password account on the server. All other account HTML pages can be replaced similarly by looking in the configuration where the template file occurs. All template files can be found here.

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