Most server behaviour is fixed at process start. The surreal db start command is the primary entry point: pass flags for bind addresses, storage paths, authentication, TLS material, logging, and feature toggles.
Review the command reference whenever you upgrade, as defaults and supported flags can change between releases. Keep a short changelog of server flags per environment so rollbacks and comparisons stay straightforward.
Equivalent settings are often available as environment variables, which suits containers, systemd units, and secret managers. Prefer one coherent source of truth (file, env, or flags) so configuration does not diverge silently across hosts.
Running in the background. surreal db start runs in the foreground and has no daemon mode of its own, so let the operating system's service manager start it, restart it after a failure, and stop it cleanly. In a container, docker run -d runs the same server in the background.
On Linux, let systemd run the server. Save the following as /etc/systemd/system/surrealdb.service, then run sudo systemctl enable --now surrealdb:
[Unit]
Description=SurrealDB server
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=surrealdb
Group=surrealdb
EnvironmentFile=/etc/surrealdb/surrealdb.env
ExecStart=/usr/local/bin/surreal db start
Restart=on-failure
LimitNOFILE=infinity
[Install]
WantedBy=multi-user.targetThe unit reads its settings from the environment file, which keeps the root password out of the unit file and the process list. The variable names are those on the environment variables page:
SURREAL_USER=root
SURREAL_PASS=secret
SURREAL_BIND=127.0.0.1:8000
SURREAL_PATH=rocksdb:///var/lib/surrealdb/dataRestrict the file with chmod 600, and make sure the surrealdb user owns the data directory. Use journalctl -u surrealdb -f to follow the server log.
Storage engines are selected by the path on surreal db start. For most self-hosted servers, use RocksDB (rocksdb://…) for on-disk production data. The default memory backend (SurrealMX) suits development and tests as well as solutions that make use of its Redis-like persistent storage, while the optional SurrealKV (surrealkv://…, beta) is an alternative single-node disk engine with a smaller tuning surface. Capacity planning, backups, and versioning options differ by engine - see the Deployment models and Run a single-node, on-disk server pages for more.
Bind address and port determine where clients and operators reach the server. Restrict admin interfaces to trusted networks, use a load balancer or service mesh for TLS termination if that matches your platform, and document ports for HTTP, WebSocket, and any separate metrics endpoints you expose.
Firewall rules should default to deny: allow only the subnets and ports your applications and operators require.
Set authentication and root user credentials explicitly in production. Root credentials grant broad access: rotate them on a schedule, store them in a vault, and avoid reusing development passwords.
TLS: supply certificates and keys via surreal db start or env vars so wire traffic is encrypted. Renew certificates before expiry, pin trusted CAs where appropriate, and consider a reverse proxy for advanced policies while keeping SurrealDB’s own TLS configuration minimal and auditable.
After changes, confirm the effective configuration by inspecting startup logs and probing only the intended listeners. In regulated environments, record who approved credential and TLS updates and when they took effect.