Servers

Starting a Server

GUI

After opening a database, click Server > Quick Start or Server > Advanced Start. Quick start immediately starts a server on the default port (28260) using the default config. Advanced start prompts you to set the port and config, with a Basic Config tab for setting just global permissions, and a Full Config tab for providing a full YAML config.

CLI

Use the command server start [--port=<port>] ([--global_perms=<perms>] | [--config_file=<file>] [--config=<config>] [--verbose]) to start a server. --global_perms accepts comma-separated permission matchers. --config_file uses the contents of the specified file for the config. If it is pointed to a folder, it automatically uses the file config.yaml within that folder. --config can either be used to specify the config outright or modify the config from --config_file. (The modifications aren't saved to the file.) It uses a modified version of YAML, where: (1) entries are semicolon-separated, (2) keys include dots rather than being nested, and (3) the colon separating the key and value doesn't require a space afterward. Use --verbose to see the final YAML that will be parsed to generate the config.

Examples:

• server start: Starts the server using the default config
• server start --global_perms=viewer_anyone: Starts the server using the default config, except the authorization manager is permission, the permission manager is global, and the global permission manager's permissions are all of the permissions under the role viewer_anyone
• server start --config_file=config.yaml: Starts the server using the file config.yaml for the config
• server start --config=ssl.mode:optional;ssl.chain_file:cert.pem;ssl.private_key_file:private_key.pem: Starts the server using the default config, except SSL is enabled
• server start --config_file=server --config=website_enabled:true: Starts the server using the file server/config.yaml for the config, except the website is enabled

Programmatically

See the Connection Module.

Server Config

The server config is not related to the database config. It contains settings on how the server itself should run, and in particular, what requests should be allowed. See the default config.yaml for details.

Authorizing Requests

You can configure which requests are allowed using an authorization manager. Most likely, you either want to use either allow (the default), which allows all requests, or permission, which allows requests based on users' permissions. When using permission, you can further specify what system to use to grant permissions. global gives all users (including guests) the same permissions, while user_map allows individualized permissions (see the default user_map_perms.txt). See Server Permissions for more about the permissions themselves.

If you're hosting a server programmatically, you can provide a custom authorization or permission manager.

Server Template

You can export a server template, which includes config files.

GUI

Click Server > Template.

CLI

Use the command server template <folder>.

Connection Types

Users can connect via 3 different protocols: (SSL can be enabled in the config)

• nbt[s]://: A custom protocol used when making remote connections
• http[s]://: Provides the website
• ws[s]://: Wraps the nbt:// protocol in a WebSocket

See the Connection Module for details.

User Types

Type	Used For	Notes
Guest	Any logged out connection	The guest user is named guest for permissions. Since all entries have an author, no entries are owned by guest. Block guest users by not giving the /connect permission to guest.
Mojang User	Any logged in connection	This uses the same system used when logging into Minecraft servers to verify accounts. Mojang users are identified by their UUID with dashes, not their username.

Verified Flag

The verified flag attached to all entries is intended to be used as a way to see if the author actually entered the entry into the database themself. The default roles grant users the ability to verify their own entries, but not anyone else's (except for admin). Primarily this is intended to aid moderation, particularly when some users have the contributor_anyone role. Note that the contributor_self role requires users to verify their own entries when adding them.