SilverBullet is primarily configured via environment variables. This page gives a comprehensive overview of all configuration options. You can set these ad-hoc when running the SilverBullet server, or e.g. in your docker-compose file.

Network

Note: these options are primarily useful for Deno deployments, not so much for Docker.

  • SB_HOSTNAME: Set to the hostname to bind to (defaults to 127.0.0.0, set to 0.0.0.0 to accept outside connections for the local deno setup, defaults to 0.0.0.0 for docker)
  • SB_PORT: Sets the port to listen to, e.g. SB_PORT=1234, default is 3000


Authentication

SilverBullet supports basic authentication for a single user.

  • SB_USER: Sets single-user credentials, e.g. SB_USER=pete:1234 allows you to login with username “pete” and password “1234”.
  • SB_AUTH_TOKEN: Enables Authorization: Bearer <token> style authentication on the API (useful for Sync and remote HTTP storage backends).
  • SB_LOCKOUT_LIMIT: Specifies the number of failed login attempt before locking the user out (for a SB_LOCKOUT_TIME specified amount of seconds), defaults to 10
  • SB_LOCKOUT_TIME: Specifies the amount of time (in seconds) a client will be blocked until attempting to log back in.


Storage

SilverBullet supports multiple storage backends for keeping your Spaces content.

Disk storage

This is the default and simplest backend to use: a folder on disk. It is configured as follows:

  • SB_FOLDER: Sets the folder to expose. In the docker container, this defaults to /space.


AWS S3 bucket storage

It is also possible to use an S3 bucket as storage. For this, you need to create a bucket, create an IAM user and configure access to it appropriately.

Since S3 doesn’t support an efficient way to store custom metadata, this mode does require a #Database configuration (see below) to keep all file metadata.

S3 is configured as follows:

  • SB_FOLDER: Set to s3://prefix. prefix can be empty, but if set, this will prefix all files with prefix/ to support multiple spaces being connected to a single bucket.
  • AWS_ACCESS_KEY_ID: an AWS access key with read/write permissions to the S3 bucket
  • AWS_SECRET_ACCESS_KEY: an AWS secret access key with read/write permissions to the S3 bucket
  • AWS_BUCKET: the name of the S3 bucket to use (e.g my-sb-bucket)
  • AWS_ENDPOINT: e.g. s3.eu-central-1.amazonaws.com
  • AWS_REGION: e.g. eu-central-1


Database storage

It is also possible to store space content in the #Database. While not necessarily recommended, it is a viable way to set up a simple deployment of SilverBullet on e.g. Deno Deploy. Large files will automatically be chunked to avoid limits the used database may have on value size.

This mode is configured as follows:

  • SB_FOLDER: set to db://


The database configured via #Database will be used.

HTTP storage

While not particularly useful stand-alone (primarily for Sync), it is possible to store space content on another SilverBullet installation via its API.

This mode is configured as follows:

  • SB_FOLDER: set to the URL of the other SilverBullet server, e.g. https://mynotes.mydomain.com
  • SB_AUTH_TOKEN: matching the authorization token (configured via #Authentication on the other end) to use for authorization.


Database

SilverBullet requires a database backend to (potentially) keep various types of data:

  • Indexes for e.g. Objects
  • Storing some encryption-related secrets (for Authentication)
  • Space content, when the “Database storage” storage backend is used


Currently, only two databases are supported: Deno KV and a dummy in-memory database.

Deno KV database

When self-hosting SilverBullet (that is, on any server other than on Deno Deploy), KV uses a local SQLite file to keep data. This is efficient and performant, at least if your disk is.

If you are hosting your space on magnetic drives (e.g. on a NAS), which are slower, you may consider storing the database somewhere else. You can do this by setting the SB_KV_DB path to a path outside your space, e.g. SB_KV_DB=/var/lib/silverbullet/silverbullet.db . Alternatively, you can use SB_SYNC_ONLY or even #Memory database.

If you use Docker, and set SB_KV_DB, make sure you bind mount an external folder into your container for this data to be persistent, e.g. by passing -v /var/lib/space_db:/var/lib/silverbullet to your docker run command.

KV can be configured as follows:

  • SB_DB_BACKEND: kv (default, so can be omitted)
  • SB_KV_DB: path to the file name of the (SQLite) database to store data in, defaults to .silverbullet.db in the space’s folder (when kept on disk).


When SilverBullet runs on Deno Deploy it automatically uses its cloud implementation of KV.

Memory database

The in-memory database is primarily useful for testing. It can be useful to reduce I/O on slow drives, with the following caveats:

  • On restart, it'll have to rebuild the cache
  • If SB_USER authentication is in use, you will be logged out.


To use this, configure like so:

  • SB_DB_BACKEND: memory


Run mode

  • SB_SYNC_ONLY: If you want to run SilverBullet in a mode where the server purely functions as a simple file store and doesn’t index or process content on the server, you can do so by setting this environment variable to true. As a result, the client will always run in the Sync client mode. This can also be useful for slow drives, as the server will not perform indexing I/O.
  • SB_READ_ONLY (Experimental): If you want to run the SilverBullet client and server in read-only mode (you get the full SilverBullet client, but all edit functionality and commands are disabled), you can do this by setting this environment variable to true. Upon the server start a full space index will happen, after which all write operations will be disabled.


Security

SilverBullet enables plugs to run shell commands. This is used by e.g. the Git plug to perform git commands. This is potentially unsafe. If you don’t need this, you can disable this functionality:

  • SB_SHELL_BACKEND: Enable/disable running of shell commands from plugs, defaults to local (enabled), set to off to disable. It is only enabled when using a local folder for #Storage.
  • SB_SPACE_SCRIPT: Enable/disables Space Script. Defaults to on, set to off to disable this feature altogether.



Docker

Configuration only relevant to docker deployments:

  • PUID: Runs the server process with the specified UID (default: whatever user owns the /space mapped folder)
  • GUID: Runs the server process with the specified GID (default: whatever group owns the /space mapped folder)


Web app manifest

Configure aspects of web app appearance:

  • SB_NAME: Sets name and short_name members of web app manifest to whatever specified in SB_NAME
  • SB_DESCRIPTION: Sets description member of web app manifest to whatever specified in SB_DESCRIPTION