clockworklabs/SpacetimeDB · error

Server already configured for host: {host}

Error message

Server already configured for host: {host}

What it means

Thrown by Config::add_server (the code behind `spacetime server add`) when a server configuration already exists for the given host. The CLI keeps a list of server_configs and enforces one entry per host so that name lookups stay unambiguous; just above this check it also rejects a new host equal to an existing server's nickname. The config persists in the CLI's TOML config file, so the conflict survives across invocations.

Source

Thrown at crates/cli/src/config.rs:243

    ) -> anyhow::Result<()> {
        if let Some(nickname) = &nickname
            && let Ok(cfg) = self.find_server(nickname)
        {
            anyhow::bail!(
                "Server nickname {} already in use: {}://{}",
                nickname,
                cfg.protocol,
                cfg.host,
            );
        }

        if let Ok(cfg) = self.find_server(&host) {
            if let Some(nick) = &cfg.nickname
                && nick == &host
            {
                anyhow::bail!("Server host name is ambiguous with existing server nickname: {nick}");
            }
            anyhow::bail!("Server already configured for host: {host}");
        }

        self.server_configs.push(ServerConfig {
            nickname,
            host,
            protocol,
            ecdsa_public_key,
        });
        Ok(())
    }

    fn host(&self, server: &str) -> anyhow::Result<&str> {
        self.find_server(server)
            .map(|cfg| cfg.host.as_ref())
            .with_context(|| format!("Cannot find hostname for unknown server: {server}"))
    }

    fn default_host(&self) -> anyhow::Result<&str> {

View on GitHub (pinned to 524b4487d9)

Solutions

1. Run `spacetime server list` to confirm the host is already configured, then reuse that entry (e.g. `spacetime server set-default <name>`) instead of adding again
2. If the existing entry is stale or wrong, remove/edit it via the `spacetime server` subcommands so the host becomes free, then re-run add
3. Make provisioning scripts idempotent: grep `spacetime server list` for the host before calling add

Example fix

# before (fails on the second run)
spacetime server add http://localhost:3000 local --default

# after (idempotent setup)
spacetime server list | grep -q localhost:3000 || \
  spacetime server add http://localhost:3000 local --default

#!/usr/bin/env bash
# Before provisioning, confirm the host is not already configured
HOST='localhost:3000'
if ! spacetime server list | grep -q "$HOST"; then
  spacetime server add "http://$HOST" local --default
fi

match config.add_server(nickname, host, protocol, key) {
    Ok(()) => {}
    Err(e) if e.to_string().starts_with("Server already configured for host") => {
        // idempotent provisioning: treat as success
    }
    Err(e) => return Err(e),
}

When it happens

Trigger: Calling `spacetime server add <name> <protocol>://<host>` (or add_server programmatically) when find_server(&host) already resolves to an entry in the saved config. Typically: running the add command a second time with the same URL/host, or adding the same host under a different nickname/protocol.

Common situations: Setup or CI scripts that run `spacetime server add` unconditionally on every run; re-adding mainnet/testnet/localhost after switching or restoring a config file; onboarding docs that say 'add the server' without an idempotency check.

Related errors

• Host {} conflicts with saved configuration for server {}: {}
• Server nickname {} already in use: {}://{}
• Nickname {} conflicts with saved configuration for server {}
• Invalid subcommand: {unknown}
• Invalid url: {url}

AI-assisted analysis of clockworklabs/SpacetimeDB@524b4487d9 (2026-08-16). Data as JSON: /api/errors/e87f43269f30163c. Report an issue: GitHub.