Server Configuration

Most production settings are managed in the interface. Open the user menu, select Settings, then expand Server.

Server settings map

Section	Purpose
General	Server identity, licence/update information, export and client connection details
Credentials	Agent-provider OAuth profiles and API keys
Users	Accounts, roles, seats, and access
Mobile notifications	Push-notification provider configuration
Authentication	Password login and OIDC SSO
Boards	Server-wide board defaults and templates
API Keys	Scoped automation credentials and permissions
Skills	Skills installed server-wide
Integrations	External issue trackers and custom providers
Labels	Reusable server labels
Backup	Manual/scheduled backups, provider, and retention
Log Export	External log sink and output format
Encryption	Key source and safe key rotation

Organization and project settings are separate scopes. A server administrator does not need to put every project-specific label, skill, or credential in the Server section.

Network and ports

Native release builds listen on 0.0.0.0. The preferred port is 50505; if unavailable, the server tries 50506–50514, then an OS-assigned port. The actual port is written to port.txt.

Docker always exposes container port 50505; the host mapping is your choice. For remote access, use HTTPS through a reverse proxy and forward WebSocket upgrades.

The unauthenticated health endpoint is:

curl http://localhost:50505/api/health

Persistent data

Native data locations are listed in Server Binary. Docker persists the same application directory through the /data volume. The important contents include:

• data/stib.db — SQLite database in WAL mode;
• attachments and generated exports;
• backups and logs;
• update staging files and server identity;
• port.txt — last successfully bound port.

Never edit a migration already applied to a database. Normal releases run pending migrations automatically, after a backup — see Backups before migrations.

Encryption

Credential and integration secrets are encrypted. Key resolution order is:

1. valid STIB_ENCRYPTION_KEY environment value;
2. key stored in the database;
3. a newly generated key, persisted on first launch.

When an environment key is active, the UI does not replace it. Rotate it through deployment configuration and the supported rotation flow; never simply start the existing database with a different key.

Common environment variables

Variable	Meaning
RUST_LOG	Rust log filter, for example info or stib_server=debug
STIB_ENCRYPTION_KEY	External 32-byte key encoded as 64 hexadecimal characters
STIB_SERVER_ORIGIN	Public origin used to construct OIDC callbacks
STIB_RELEASE_CHANNEL	stable or beta
STIB_UPDATE_URL	Override the signed update-manifest endpoint
STIB_WEBSITE_API_URL	Override the stib.ai account/licence API
STIB_AGENT_IMAGE	Agent sandbox image used by a Docker-capable server
STIB_API_URL	Public server-origin fallback, and API target for human or external CLI processes; it is not reused as an agent's private route
STIB_AGENT_API_URL	Explicit private server origin for agent runtimes; direct agents default to loopback and Docker sandboxes to host.docker.internal
STIB_ALLOW_REMOTE_CALLBACK	Allow agent callbacks from trusted RFC1918 addresses; off by default
STIB_ALLOW_PRIVATE_URLS	Allow server-connection integration URLs resolving to private networks; off by default
STIB_SKIP_PRE_MIGRATION_BACKUP	Apply pending migrations without the automatic backup — and so without automatic rollback; off by default

The two ALLOW_… switches broaden network reach. Enable them only for a deliberate, trusted deployment design. STIB_ALLOW_PRIVATE_URLS covers server connections only: a connection owned by a project stays on public hosts whatever the environment says.

Backups

Use Settings → Server → Backup to create a consistent backup and configure scheduling/retention. Prefer that flow to copying an actively written SQLite file. Verify that backups are stored outside the failure domain you are protecting against.

An export is useful for portability, but it is not the same as a complete operational backup. Test restoration before relying on a backup policy.

Backups before migrations

When a new version starts on an existing database that it has to migrate, it first writes a backup named stib-pre-migration-<date>.db to data/backups/, then applies the migrations. Whatever the update path — installer, Docker image, or a binary replaced by hand — this happens at startup, before the server accepts any request.

• If a migration fails, the server puts that backup back in place of the partly migrated database and stops. The database is exactly as the previous version left it: reinstall that version, or wait for a release that fixes the migration.
• If the backup cannot be written — usually because the disk cannot hold a copy of the database — the server stops without migrating anything. Free some space, or set STIB_SKIP_PRE_MIGRATION_BACKUP=1 to migrate without a rollback point.

These backups are always stored locally, whatever storage provider is configured, and the three most recent are kept. They are compressed, and encrypted when a backup key is configured, like every other backup. With S3 or WebDAV configured, they do not appear in the backup list; open the backup folder to find them.

Logs

Server logs are stored below the application data directory. Log Export can forward structured records to a configured destination. The desktop app has a separate native-log export for client-side diagnostics.

Do not include access tokens, API keys, credential payloads, or full private prompts in a support bundle unless the recipient and channel are trusted.

Next: Authentication, Integrations, and Settings.