# start

A command that begins a running instance of a SurrealDB server with arguments to set the storage backend, authentication and more.

The start command starts a SurrealDB server in memory, on disk, or in a distributed setup.

> [!NOTE]
> **Before you start** — make sure you’ve [installed SurrealDB](/docs/running/installation.md).

<Synopsis>
surreal start [OPTIONS] [PATH]
</Synopsis>

<OptionsTable
    title="Arguments"
    options={[
        {
            "name": "[PATH]",
            "default": "memory",
            "env": "SURREAL_PATH",
            "description": "Where the server stores data. Combine a backend name with `:` or `://` and an address or filename, for example `surrealkv://mydb` or `rocksdb:database`. See the Positional argument section below."
        }
    ]}
/>

<OptionsTable
    title="Options"
    options={[
        {
            "name": "--bind",
            "short": "-b",
            "value": "<LISTEN_ADDRESSES>",
            "default": "127.0.0.1:8000",
            "env": "SURREAL_BIND",
            "description": "The hostname or IP address to listen for connections on."
        },
        {
            "name": "--postgres-bind",
            "description": "The hostname or IP address to listen for Postgres wire protocol connections on, for example `127.0.0.1:5432`. The listener is disabled when omitted."
        },
        {
            "name": "--client-ip",
            "value": "<CLIENT_IP>",
            "default": "socket",
            "env": "SURREAL_CLIENT_IP",
            "description": "The method of detecting the client's IP address. Possible values: `none`, `socket`, `CF-Connecting-IP`, `Fly-Client-IP`, `True-Client-IP`, `X-Real-IP`, `X-Forwarded-For`, `Forwarded`."
        },
        {
            "name": "--import-file",
            "value": "<IMPORT_FILE>",
            "env": "SURREAL_IMPORT_FILE",
            "description": "Path to a SurrealQL (`.surql`) file that is imported when starting the server."
        },
        {
            "name": "--username",
            "short": "-u",
            "value": "<USERNAME>",
            "env": "SURREAL_USER",
            "description": "The username for the initial database root user, applied only if no other root user exists. Alias: `--user`."
        },
        {
            "name": "--password",
            "short": "-p",
            "value": "<PASSWORD>",
            "env": "SURREAL_PASS",
            "description": "The password for the initial database root user, applied only if no other root user exists. Alias: `--pass`."
        },
        {
            "name": "--unauthenticated",
            "env": "SURREAL_UNAUTHENTICATED",
            "description": "Whether to allow unauthenticated access. See Unauthenticated mode below."
        },
        {
            "name": "--no-identification-headers",
            "env": "SURREAL_NO_IDENTIFICATION_HEADERS",
            "description": "Whether to suppress the server name and version headers."
        },
        {
            "name": "--temporary-directory",
            "value": "<TEMPORARY_DIRECTORY>",
            "env": "SURREAL_TEMPORARY_DIRECTORY",
            "description": "The directory for storing temporary database files."
        },
        {
            "name": "--allow-experimental",
            "value": "<TARGETS>",
            "env": "SURREAL_CAPS_ALLOW_EXPERIMENTAL",
            "description": "Experimental capabilities to enable, as a comma-separated list. Possible values: `files`, `surrealism`."
        },
        {
            "name": "--durable-sessions",
            "env": "SURREAL_DURABLE_SESSIONS",
            "description": "Whether to persist client-attached HTTP RPC sessions in the datastore. Off by default."
        },
        {
            "name": "--durable-session-ttl",
            "value": "<DURABLE_SESSION_TTL>",
            "default": "24h",
            "env": "SURREAL_DURABLE_SESSION_TTL",
            "description": "Idle lifetime of a persisted HTTP RPC session before it expires. Each use refreshes the expiry."
        },
        {
            "name": "--durable-session-gc-interval",
            "value": "<DURABLE_SESSION_GC_INTERVAL>",
            "default": "60s",
            "env": "SURREAL_DURABLE_SESSION_GC_INTERVAL",
            "description": "Interval for purging expired durable HTTP RPC sessions. Set `0` to disable the sweep."
        },
        {
            "name": "--log",
            "short": "-l",
            "value": "<LOG>",
            "default": "info",
            "env": "SURREAL_LOG",
            "description": "The logging level for the database server. Possible values: `none`, `full`, `error`, `warn`, `info`, `debug`, `trace`."
        }
    ]}
/>

`surreal start` has more options than any other subcommand, and the table above covers the ones described on this page. The remaining groups — database tuning, datastore TLS, HTTP server, capabilities, and logging — are listed in full in the [command help](#command-help) below, and mapped to their variables on the [environment variables](/docs/reference/cli/surrealdb-cli/environment-variables.md) page.

Two of the flags above are documented in more detail elsewhere: `--postgres-bind` exposes the [Postgres wire protocol](/docs/reference/rest-api/postgres-protocol.md), and the `--durable-*` flags are explained under [Durable HTTP RPC sessions](#durable-http-rpc-sessions). The `Forwarded` value for `--client-ip` reads the RFC 7239 `Forwarded` header. _(since v3.1.0)_

## Positional argument

> [!WARNING]
> FoundationDB support is deprecated in SurrealDB `3.0`. Please plan to migrate to a supported storage backend.

In the `surreal start` command, the path argument is used to specify the location of the database. If no argument is given, the default of `memory` for storage [in memory](/docs/running/in-memory.md) is assumed.

Arguments for persistent backends are a combination of the backend name, a `:` or `://`, and an address or filename — for example `surrealkv://mydb` or `rocksdb:database`. The available backends are:

- `memory` (or no argument) for in-memory storage
- `rocksdb` for RocksDB
- `surrealkv` for SurrealKV
- `indxdb` for IndexedDB
- `tikv` for TiKV

### Absolute vs. relative paths

The datastorage flavour (`rocksdb`, `surrealkv`, etc.) followed by `:` or `://` will be recognised as a relative path. Any other number of slashes such as `rocksdb:/path` or `surrealkv:///path` will be interpreted as an absolute path. As a short absolute path of this nature will often require elevated permissions, the output for this command may end in this sort of error.

```text
Failed to create RocksDB directory: `Os { code: 30, kind: ReadOnlyFilesystem, message: "Read-only file system" }`.
```

If you see this error without having intended to start the server on an absolute path, it is likely that the path passed in unintentionally contains either one slash or more than two slashes.

> [!NOTE]
> Be sure not to use multiple storage backends in the same location, such as `rocksdb://path/to/database` followed by `surrealkv://path/to/database`. As storage is entirely delegated to the backend, the CLI is not aware of the structure of the data itself. While each backend uses its own file names and directory structure to store data, it is possible that data overwrite or other issues may occur.

> [!IMPORTANT]
> **TiKV** (`tikv://…`) is supported for local multi-node experimentation with the Community edition. Production multi-node HA uses distributed storage on [SurrealDB Cloud Scale](https://surrealdb.com/pricing/scale) or [SurrealDB Enterprise](https://surrealdb.com/enterprise). See [Run a multi-node cluster](/docs/running/multi-node.md) and [Deployment](/docs/manage/self-hosted/deployment-models.md). To provision and scale those instances from a script rather than a browser, see [`surrealctl`](/docs/reference/cli/surrealctl/overview.md).

## Getting started

This example will show how to host a SurrealDB server with the `surreal start` command, and then access the Surreal DB server using the [`surreal sql` command](/docs/reference/cli/surrealdb-cli/commands/sql.md).

To start a SurrealDB server, run the `surreal start` command, using the options below. This example stores the database in memory, with a username and password, hosted at `127.0.0.1:8000` (the default location).

```bash
surreal start memory --user my_username --pass my_password
```

The server is actively running, and can be left alone until you want to stop hosting the SurrealDB server.

> [!NOTE]
> The message "Started web server on 127.0.0.1:8000", indicates where the server is being hosted and can be accessed by clients. The location `127.0.0.1:8000` is the default, and can be manually changed by specifying the `--bind` option of the `surreal start` command.

To access the SurrealDB server that you have started hosting, open a new terminal which will act as the client, while the previous terminal is still running the `surreal start` command described above. This is done using a separate [`surreal sql`](/docs/reference/cli/surrealdb-cli/commands/sql.md) command. Ensure that the hosting location indicated by the output of the `surreal start` command is passed to the `--endpoint` argument, and that you specify the same `--username` and `--password` as in the `surreal start` command.

A particular namespace and database can be specified at this point, as seen below.

```bash
surreal sql --endpoint http://127.0.0.1:8000 --namespace my_namespace \
  --database my_database --username my_username --password my_password
```

## Using environment variables

> [!IMPORTANT]
> Most of the flags above have a corresponding [environment variable](/docs/reference/cli/surrealdb-cli/environment-variables.md#command-environment-variables).
> For example, the `--temporary-directory` flag can be configured with the `SURREAL_TEMPORARY_DIRECTORY` environment variable instead.

When using the `surreal start` command, you can also use environment variables to set the values for the command-line flags. This is useful when you want to set the values for the command-line flags without having to pass them directly on the command line.

For more on the environment variables available for CLI commands or SurrealDB instances in general, see the [environment variables](/docs/reference/cli/surrealdb-cli/environment-variables.md#command-environment-variables) page.

## Strict mode

Versions before SurrealDB 3.0 contained a flag to start the entire server in strict mode. When running in strict mode, no `NAMESPACE`, `DATABASE`, or `TABLE` definitions were enacted automatically when data is inserted. Any queries would return an error if the selected namespace, database, or table were not specifically defined in advance.

```bash
surreal start --strict --log debug memory
```

Since SurrealDB 3.0, strict mode is now enacted on the database level via a [`DEFINE DATABASE`](/docs/reference/query-language/statements/define/database.md) statement.

```surql
DEFINE DATABASE my_anything_goes_db;
DEFINE DATABASE my_strict_db STRICT;
```

## Datastore configuration

**3.x**

Configuring a datastore is done by passing in a string that begins with the datastore name, a path if persistent storage is needed, and optional parameters. Some examples:

```bash
surreal start --user root --pass secret "surrealkv://path/to/db?versioned=true&sync=every&retention=30d"
surreal start --user root --pass secret "mem://tmp/data?versioned=true&aol=sync&snapshot=60s&sync=5s"
surreal start --user root --pass secret "mem://?versioned=true"
```

Each database store supports different parameters.

### Supported parameters for Memory (SurrealMX)

- `versioned` (`true` or `false`)
- `retention` (a duration string, e.g. `30d`, `24h`, `30m`)
- `aol` (`never`, `sync`, or `async`), for writing changes to an append-only log file
- `snapshot` (a duration string, e.g. `60s`), for periodically writing a snapshot of the database to the file system
- `sync` (`never`, `every`, or a duration string like `5s`), for specifying when to flush the append-only log file to the file system
  - `never` - (default) leave flushing to the OS (least durable)
  - `every` - sync on every commit (most durable)
  - `interval` - periodic background flushing at the given interval

Persistence for the memory backend is used for the following:

- Append-Only Log (AOL) - Synchronous/asynchronous modes for durability
- Snapshots - Periodic full database state capture
- Data Recovery - Automatic recovery from snapshots + AOL on startup
- AOL Truncation - Automatic cleanup after snapshots

### Supported parameters for SurrealKV
- `versioned` (`true` or `false`)
- `retention` (a duration string, e.g. `30d`, `24h`, `30m`)
- `sync` (`never`, `every`, or a duration string like `5s`), for specifying when to flush the database to the file system
  - `every` - (default) sync before completing and confirming each transaction (most durable)
  - `never` - leave flushing to the OS (least durable)
  - `interval` - periodic background flushing at the given interval

### Supported parameters for RocksDB
- `sync` (`never`, `every`, or a duration string like `5s`), for specifying when to flush the database to the file system
  - `every` - (default) sync before completing and confirming each transaction (most durable)
  - `never` - leave flushing to the OS (least durable)
  - `interval` - periodic background flushing at the given interval

**2.x**

To start a SurrealDB instance with RocksDB as the storage engine, include the `rocksdb://` prefix in the path argument.

```bash
surreal start -u root -p secret rocksdb://mydb
```

To start a SurrealDB instance with SurrealKV as the storage engine, include the `surrealkv://` prefix in the path argument.

```bash
surreal start -u root -p secret surrealkv://mydb
```

While SurrealKV supports historical/temporal querying using the `VERSION` clause when [selecting](/docs/reference/query-language/statements/select.md#the-version-clause) data, you must explicitly opt in to this using the `surrealkv+versioned://` prefix in the path argument.

```bash
surreal start -u root -p secret surrealkv+versioned://mydb
```

## Authentication

When starting a SurrealDB instance, authentication is enabled by default, and your user credentials will be required to connect. If you are starting a new instance, the user credentials you use to run the `start` command will [define a new root user](/docs/reference/query-language/statements/define/user.md#roles) with the [`OWNER`](/docs/reference/query-language/statements/define/user.md#roles) role.

```bash
surreal start --user root --password root
```

## Enabling capabilities

> [!NOTE]
> If using SurrealDB Cloud, capabilities can be set from [SurrealDB Studio](/docs/manage/instances/configure.md#capabilities) or with [`surrealctl`](/docs/reference/cli/surrealctl/overview.md).

Capabilities arguments such as `allow-scripting` or `deny-net` can also be passed into the `surreal start` command. These arguments, the order in which they are evaluated, and other notes on security are presented in detail in a [separate page on capabilities](/docs/learn/security/authorization/capabilities.md).

A production-oriented example of the `surreal start` command that begins with the `--deny-all` flag and only thereafter sets which capabilities will be allowed:

```bash
surreal start --deny-all --allow-funcs "array, string, crypto::argon2, http::get" --allow-net api.example.com:443
```

## Unauthenticated mode

> [!NOTE]
> We recommend enabling authentication when running SurrealDB in production or in publicly exposed ways. Failure to do so may result in unauthorised access.

Using the `--unauthenticated` flag, you can also start a SurrealDB instance in unauthenticated mode. By doing so, authentication will be disabled. In this mode, any guest user is considered to have the same permissions as a root user with the [`OWNER`](/docs/reference/query-language/statements/define/user.md#roles) role.

To start a SurrealDB instance in unauthenticated mode, run the following command:

```bash
surreal start --unauthenticated
```

## Identification headers

By default, SurrealDB includes headers in the HTTP response that identify the server name and version. You can suppress these headers by using the `--no-identification-headers` flag.

```bash
surreal start --no-identification-headers
```

## Durable HTTP RPC sessions

_(since v3.2.2)_

Client-attached sessions on the HTTP [`/rpc`](/docs/reference/rest-api/rpc-protocol.md) endpoint normally live only in the process memory of the node that created them. After a restart, or when a later request is routed to a different node, the client receives a session-not-found error.

The `--durable-sessions` flag can be used to store those sessions in the datastore so they survive restarts and can be resumed on any node that shares the same storage. Each use refreshes a sliding idle TTL (`--durable-session-ttl`, default `24h`). A background task removes expired entries (`--durable-session-gc-interval`, default `60s`; set `0` to disable the sweep). Expired sessions are still dropped when loaded.

```bash
surreal start --durable-sessions --durable-session-ttl 12h rocksdb://mydb
```

> [!WARNING]
> The durable copy includes the session's authentication state and is stored **unencrypted** in the datastore. Sticky routing is recommended so a given session is used on one node at a time. Concurrent use from multiple nodes is best-effort.

WebSocket connections keep in-memory sessions only. This mode does not change WebSocket behaviour.

## Experimental capabilities

_(since v2.2.0)_

> [!NOTE]
> The experimental capability is completely hidden in the CLI help command, and `--allow-all` will not enable the experimental capabilities by default.

To use experimental capabilities, set the `SURREAL_CAPS_ALLOW_EXPERIMENTAL` [environment variable](/docs/reference/cli/surrealdb-cli/environment-variables.md) to the experimental capability you want to allow.

For example, to use [Surrealism](/docs/learn/extensions/plugins/overview.md) extensions, set the `SURREAL_CAPS_ALLOW_EXPERIMENTAL` environment variable to `surrealism` - or pass it in via the `--allow-experimental` flag.

```bash
# Allow experimental via an env var
SURREAL_CAPS_ALLOW_EXPERIMENTAL=surrealism surreal start

# Allow experimental via a flag
surreal start --allow-experimental surrealism
```

Multiple experimental capabilities can be enabled by separating them with a comma.

```bash
SURREAL_CAPS_ALLOW_EXPERIMENTAL=surrealism,files surreal start
surreal start --allow-experimental surrealism,files
```

> [!NOTE]
> Experimental capabilities are enforced on the **server** for remote clients. If you use [`surreal sql`](/docs/reference/cli/surrealdb-cli/commands/sql.md) against `ws://` or `http://`, configure flags here — not only on the REPL. See [Capabilities and remote connections](/docs/reference/cli/surrealdb-cli/commands/sql.md#capabilities-and-remote-connections).

> [!NOTE]
> From **3.3.0**, [ISO GQL](/docs/learn/querying/gql/overview.md) is enabled by default and no longer uses an experimental capability. The legacy tag `gql` is still accepted for compatibility but has no effect. On **3.2.x**, use `--allow-experimental gql`.

| Example feature/statement | Tag |
| --- | --- |
| [DEFINE BUCKET](/docs/reference/query-language/statements/define/bucket.md) | `files` |
| [DEFINE MODULE](/docs/reference/query-language/statements/define/module.md) | `surrealism` |
| [Writes inside create, update, and delete permission clauses](/docs/reference/query-language/statements/define/table.md#writes-inside-a-permission-clause) | `mutable_permissions` |

> [!NOTE]
> `mutable_permissions` does not work like the tags above. From 3.3.0 a server enables it on its own, so you never pass it to `--allow-experimental`. Name it in `--deny-experimental` or `SURREAL_CAPS_DENY_EXPERIMENTAL` to turn it off. Embedded engines still have it off by default and must allow it explicitly.

## Further examples

As `surreal start` is the command with by far the largest number of options, a few more examples will help give an idea of what sort of configurations are available.

An instance with a single root user, able to connect to the internet but unable to use three functions:

```bash
surreal start --user root --pass secret --allow-net --deny-funcs "crypto::md5, http::post, http::delete"
```

An instance with more verbose logging that uses RocksDB as its storage engine:

```bash
surreal start --log debug rocksdb:mydatabase.db
```

An instance with all capabilities denied except a few functions and a single endpoint:

```bash
surreal start --deny-all --allow-funcs "array, string, crypto::argon2, http::get" --allow-net api.example.com:443
```

An instance with a different default address, less verbose logging level, and ability to use JavaScript functions:

```bash
surreal start --bind 0.0.0.0:2218 --log warn --allow-scripting
```

## Command help

To see the help information and usage instructions, in a terminal run the `surreal start --help` command without any further arguments. This command gives general information on the arguments, inputs, and additional options for the `start` command.

```bash
surreal start --help
```

The output of the above command:

```text
Start the database server

Usage: surreal start [OPTIONS] [PATH]

Arguments:
  [PATH]
          Database path used for storing data

          [env: SURREAL_PATH=]
          [default: memory]

Options:
      --no-banner
          Whether to hide the startup banner

          [env: SURREAL_NO_BANNER=]

      --index-compaction-interval <INDEX_COMPACTION_INTERVAL>
          [env: SURREAL_INDEX_COMPACTION_INTERVAL=]
          [default: 5s]

      --async-event-interval <EVENT_PROCESSING_INTERVAL>
          [env: SURREAL_ASYNC_EVENT_PROCESSING_INTERVAL=]
          [default: 5s]

  -h, --help
          Print help (see a summary with '-h')

Database:
      --node-membership-refresh-interval <NODE_MEMBERSHIP_REFRESH_INTERVAL>
          The interval at which to refresh node registration information

          [env: SURREAL_NODE_MEMBERSHIP_REFRESH_INTERVAL=]
          [default: 3s]

      --node-membership-check-interval <NODE_MEMBERSHIP_CHECK_INTERVAL>
          The interval at which to process and archive inactive nodes

          [env: SURREAL_NODE_MEMBERSHIP_CHECK_INTERVAL=]
          [default: 15s]

      --node-membership-cleanup-interval <NODE_MEMBERSHIP_CLEANUP_INTERVAL>
          The interval at which to process and cleanup archived nodes

          [env: SURREAL_NODE_MEMBERSHIP_CLEANUP_INTERVAL=]
          [default: 300s]

      --changefeed-gc-interval <CHANGEFEED_GC_INTERVAL>
          The interval at which to perform changefeed garbage collection

          [env: SURREAL_CHANGEFEED_GC_INTERVAL=]
          [default: 30s]

      --query-timeout <QUERY_TIMEOUT>
          The maximum duration that a set of statements can run for

          [env: SURREAL_QUERY_TIMEOUT=]

      --transaction-timeout <TRANSACTION_TIMEOUT>
          The maximum duration that any single transaction can run for

          [env: SURREAL_TRANSACTION_TIMEOUT=]

      --durable-sessions
          Whether to persist client-attached HTTP RPC sessions in the datastore so they survive server restarts and can be resumed on any cluster node. Intended for deployments that route a given session to one node at a time (sticky routing / one runtime per session); a session used concurrently from multiple nodes is best-effort. The durable copy contains the session's authentication state, stored unencrypted in the datastore

          [env: SURREAL_DURABLE_SESSIONS=]

      --durable-session-ttl <DURABLE_SESSION_TTL>
          How long a persisted RPC session survives without being used; each use refreshes the expiry

          [env: SURREAL_DURABLE_SESSION_TTL=]
          [default: 24h]

      --durable-session-gc-interval <DURABLE_SESSION_GC_INTERVAL>
          The interval at which expired persisted RPC sessions are purged (0 to disable)

          [env: SURREAL_DURABLE_SESSION_GC_INTERVAL=]
          [default: 60s]

Authentication:
  -u, --username <USERNAME>
          The username for the initial database root user. Only if no other root user exists

          [env: SURREAL_USER=]
          [aliases: --user]

  -p, --password <PASSWORD>
          The password for the initial database root user. Only if no other root user exists

          [env: SURREAL_PASS=]
          [aliases: --pass]

      --unauthenticated
          Whether to allow unauthenticated access

          [env: SURREAL_UNAUTHENTICATED=]

Datastore connection:
      --kvs-ca <KVS_CA>
          Path to the CA file used when connecting to the remote KV store

          [env: SURREAL_KVS_CA=]

      --kvs-crt <KVS_CRT>
          Path to the certificate file used when connecting to the remote KV store

          [env: SURREAL_KVS_CRT=]

      --kvs-key <KVS_KEY>
          Path to the private key file used when connecting to the remote KV store

          [env: SURREAL_KVS_KEY=]

HTTP server:
      --web-crt <WEB_CRT>
          Path to the certificate file for encrypted client connections

          [env: SURREAL_WEB_CRT=]

      --web-key <WEB_KEY>
          Path to the private key file for encrypted client connections

          [env: SURREAL_WEB_KEY=]

      --client-ip <CLIENT_IP>
          The method of detecting the client's IP address

          Possible values:
          - none:             Don't use client IP
          - socket:           Raw socket IP
          - CF-Connecting-IP: Cloudflare connecting IP
          - Fly-Client-IP:    Fly.io client IP
          - True-Client-IP:   Akamai, Cloudflare true client IP
          - X-Real-IP:        Nginx real IP
          - X-Forwarded-For:  Industry standard header used by many proxies
          - Forwarded:        RFC 7239 Forwarded header (for=)

          [env: SURREAL_CLIENT_IP=]
          [default: socket]

  -b, --bind <LISTEN_ADDRESSES>
          The hostname or IP address to listen for connections on

          [env: SURREAL_BIND=]
          [default: 127.0.0.1:8000]

      --no-identification-headers
          Whether to suppress the server name and version headers

          [env: SURREAL_NO_IDENTIFICATION_HEADERS=]

Capabilities:
  -A, --allow-all
          Allow all capabilities except for those more specifically denied

          [env: SURREAL_CAPS_ALLOW_ALL=]

      --allow-scripting
          Allow execution of embedded scripting functions

          [env: SURREAL_CAPS_ALLOW_SCRIPT=]

      --allow-guests
          Allow guest users to execute queries

          [env: SURREAL_CAPS_ALLOW_GUESTS=]

      --allow-funcs [<ALLOW_FUNCS>...]
          Allow execution of all functions except for functions that are specifically denied. Alternatively, you can provide a
          comma-separated list of function names to allow
          Specifically denied functions and function families prevail over any other allowed function execution.
          Function names must be in the form <family>[::<name>]. For example:
           - 'http' or 'http::*' -> Include all functions in the 'http' family
           - 'http::get' -> Include only the 'get' function in the 'http' family

          [env: SURREAL_CAPS_ALLOW_FUNC=]

      --allow-arbitrary-query [<ALLOW_ARBITRARY_QUERY>...]
          Allow execution of arbitrary queries by certain user groups except when specifically denied. Alternatively, you can provide a
          comma-separated list of user groups to allow
          Specifically denied user groups prevail over any other allowed user group.
          User groups must be one of "guest", "record" or "system".

          [env: SURREAL_CAPS_ALLOW_ARBITRARY_QUERY=]

      --allow-net [<ALLOW_NET>...]
          Allow all outbound network connections except for network targets that are specifically denied. Alternatively, you can provide a
          comma-separated list of network targets to allow
          Specifically denied network targets prevail over any other allowed outbound network connections.
          Targets must be in the form of <host>[:<port>], <ipv4|ipv6>[/<mask>]. For example:
           - 'surrealdb.com', '127.0.0.1' or 'fd00::1' -> Match outbound connections to these hosts on any port
           - 'surrealdb.com:80', '127.0.0.1:80' or 'fd00::1:80' -> Match outbound connections to these hosts on port 80
           - '10.0.0.0/8' or 'fd00::/8' -> Match outbound connections to any host in these networks

          [env: SURREAL_CAPS_ALLOW_NET=]

      --allow-rpc [<ALLOW_RPC>...]
          Allow all RPC methods to be called except for routes that are specifically denied. Alternatively, you can provide a comma-separated
          list of RPC methods to allow.

          [env: SURREAL_CAPS_ALLOW_RPC=]
          [default: ]

      --allow-http [<ALLOW_HTTP>...]
          Allow all HTTP routes to be requested except for routes that are specifically denied. Alternatively, you can provide a
          comma-separated list of HTTP routes to allow.

          [env: SURREAL_CAPS_ALLOW_HTTP=]
          [default: ]

  -D, --deny-all
          Deny all capabilities except for those more specifically allowed

          [env: SURREAL_CAPS_DENY_ALL=]

      --deny-scripting
          Deny execution of embedded scripting functions

          [env: SURREAL_CAPS_DENY_SCRIPT=]

      --deny-guests
          Deny guest users to execute queries

          [env: SURREAL_CAPS_DENY_GUESTS=]

      --deny-funcs [<DENY_FUNCS>...]
          Deny execution of all functions except for functions that are specifically allowed. Alternatively, you can provide a
          comma-separated list of function names to deny.
          Specifically allowed functions and function families prevail over a general denial of function execution.
          Function names must be in the form <family>[::<name>]. For example:
           - 'http' or 'http::*' -> Include all functions in the 'http' family
           - 'http::get' -> Include only the 'get' function in the 'http' family

          [env: SURREAL_CAPS_DENY_FUNC=]

      --deny-arbitrary-query [<DENY_ARBITRARY_QUERY>...]
          Deny execution of arbitrary queries by certain user groups except when specifically allowed. Alternatively, you can provide a
          comma-separated list of user groups to deny
          Specifically allowed user groups prevail over a general denial of user group.
          User groups must be one of "guest", "record" or "system".

          [env: SURREAL_CAPS_DENY_ARBITRARY_QUERY=]

      --deny-net [<DENY_NET>...]
          Deny all outbound network connections except for network targets that are specifically allowed. Alternatively, you can provide a
          comma-separated list of network targets to deny.
          Specifically allowed network targets prevail over a general denial of outbound network connections.
          Targets must be in the form of <host>[:<port>], <ipv4|ipv6>[/<mask>]. For example:
           - 'surrealdb.com', '127.0.0.1' or 'fd00::1' -> Match outbound connections to these hosts on any port
           - 'surrealdb.com:80', '127.0.0.1:80' or 'fd00::1:80' -> Match outbound connections to these hosts on port 80
           - '10.0.0.0/8' or 'fd00::/8' -> Match outbound connections to any host in these networks

          [env: SURREAL_CAPS_DENY_NET=]

      --deny-rpc [<DENY_RPC>...]
          Deny all RPC methods from being called except for methods that are specifically allowed. Alternatively, you can provide a
          comma-separated list of RPC methods to deny.

          [env: SURREAL_CAPS_DENY_RPC=]

      --deny-http [<DENY_HTTP>...]
          Deny all HTTP routes from being requested except for routes that are specifically allowed. Alternatively, you can provide a
          comma-separated list of HTTP routes to deny.

          [env: SURREAL_CAPS_DENY_HTTP=]

      --temporary-directory <TEMPORARY_DIRECTORY>
          Sets the directory for storing temporary database files

          [env: SURREAL_TEMPORARY_DIRECTORY=]

      --import-file <IMPORT_FILE>
          Path to a SurrealQL file that will be imported when starting the server

          [env: SURREAL_IMPORT_FILE=]

      --slow-log-threshold <SLOW_LOG_THRESHOLD>
          The minimum execution time in milliseconds to trigger slow query logging

          [env: SURREAL_SLOW_QUERY_LOG_THRESHOLD=]

      --slow-log-param-allow <SLOW_LOG_PARAM_ALLOW>...
          A comma-separated list of parameter names to include in slow query logs

          [env: SURREAL_SLOW_QUERY_LOG_PARAM_ALLOW=]

      --slow-log-param-deny <SLOW_LOG_PARAM_DENY>...
          A comma-separated list of parameter names to omit from slow query logs

          [env: SURREAL_SLOW_QUERY_LOG_PARAM_DENY=]

      --default-namespace <DEFAULT_NAMESPACE>
          The default namespace for a new instance

          [env: SURREAL_DEFAULT_NAMESPACE=]

      --default-database <DEFAULT_DATABASE>
          The default database for a new instance

          [env: SURREAL_DEFAULT_DATABASE=]

      --no-defaults
          Whether to disable default namespace and database creation

          [env: SURREAL_NO_DEFAULTS=]

Logging:
  -l, --log <LOG>
          The logging level for the command-line tool

          [env: SURREAL_LOG=]
          [default: info]
          [possible values: none, full, error, warn, info, debug, trace]

      --log-format <LOG_FORMAT>
          The format for terminal log output

          [env: SURREAL_LOG_FORMAT=]
          [default: text]
          [possible values: text, json]

      --log-socket <LOG_SOCKET>
          Send logs to the specified host:port

          [env: SURREAL_LOG_SOCKET=]

      --log-file-level <LOG_FILE_LEVEL>
          Override the logging level for file output

          [env: SURREAL_LOG_FILE_LEVEL=]
          [possible values: none, full, error, warn, info, debug, trace]

      --log-otel-level <LOG_OTEL_LEVEL>
          Override the logging level for OpenTelemetry output

          [env: SURREAL_LOG_OTEL_LEVEL=]
          [possible values: none, full, error, warn, info, debug, trace]

      --log-socket-level <LOG_SOCKET_LEVEL>
          Override the logging level for unix socket output

          [env: SURREAL_LOG_SOCKET_LEVEL=]
          [possible values: none, full, error, warn, info, debug, trace]

      --log-socket-format <LOG_SOCKET_FORMAT>
          The format for socket output

          [env: SURREAL_LOG_SOCKET_FORMAT=]
          [default: text]
          [possible values: text, json]

      --log-file-enabled
          Whether to enable log file output

          [env: SURREAL_LOG_FILE_ENABLED=]

      --log-file-path <LOG_FILE_PATH>
          The directory where log files will be stored

          [env: SURREAL_LOG_FILE_PATH=]
          [default: logs]

      --log-file-name <LOG_FILE_NAME>
          The name of the log file

          [env: SURREAL_LOG_FILE_NAME=]
          [default: surrealdb.log]

      --log-file-format <LOG_FILE_FORMAT>
          The format for log file output

          [env: SURREAL_LOG_FILE_FORMAT=]
          [default: text]
          [possible values: text, json]

      --log-file-rotation <LOG_FILE_ROTATION>
          The log file rotation interval

          [env: SURREAL_LOG_FILE_ROTATION=]
          [default: daily]
          [possible values: daily, hourly, never]
```