neil/silverbullet
1
0
Fork 0
Code
9f082c83a9
silverbullet/website/Install/Configuration.md
Zef Hemel 9f082c83a9
Major backend refactor (#599) 
Backend refactor
2023-12-13 17:52:56 +01:00

5.0 KiB
Raw Blame History

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 Install/Local$docker.

Network

$network

  • 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

Run mode

$runmode

  • 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 Modes.

Security

$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. Only enabled when using a local folder for $storage.

Authentication

$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 back-ends).

Storage

$storage SilverBullet support multiple storage back-ends for keeping your Space content.

Disk storage

This is default and simplest back-end 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 meta data, this mode does require a $database configuration (see below) to keep all file meta data.

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 setup a simple deployment of SilverBullet on e.g. Install/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

$database SilverBullet requires a database back-end 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 back-end 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 other server than on Install/Deno Deploy), KV uses a local SQLite file to keep data. This efficient and performant.

KV can be configured as follows:

  • SB_DB_BACKEND: denokv (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 Install/Deno Deploy it automatically uses its cloud implementation of KV.

Memory database

The in-memory database is only useful for testing.

  • SB_DB_BACKEND: memory

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)