Running sepp

Although sepp is designed first and foremost to be simple to run, and easy to set up, there are a few things to consider when running it in production. This guide is intended to help you get started with running sepp in a production environment and to provide some best practices for doing so.

The operator surface

The main way an operator interacts with sepp is through the configuration file, which is hot-reloaded on each save. This means that you can make configuration changes on the fly without incurring downtime. The admin UI is a convenient way to edit the configuration but you can also edit the file directly if you prefer. Make sure to first specify the login information for the admin UI in the configuration unless the server is listening on a local loopback address in which case no login is required.

[admin]
enabled = true

# If listen_addr = 127.0.0.1:9465 for example, then no keys are required and admin access is granted by default.
listen_addr = "192.168.1.100:9465"
keys = [
 { name = "admin", key = "generate-a-long-random-secret", role = "admin" },
 { name = "engineer", key = "another-long-random-secret", role = "operator" },
 { name = "oncall", key = "a-third-long-random-secret", role = "viewer" },
]

The most common operation is to add, remove or change queues, especially when running in strict mode. See the configuration reference for details on all the options available to you.

Production checklist

Work through these before taking real traffic.

Security & access

• Set [auth] api_keys so only known clients connect. API keys
• Serve gRPC over TLS. Enabling TLS
• Give the admin UI keys and roles or disable it entirely. Admin authentication
• Front the admin port with HTTPS, either the built-in TLS or a terminating proxy.
• Bind metrics.prometheus_listen_addr to a private interface; it defaults to 0.0.0.0:9464.

Data & durability

• Persist the data directory (db_path) on a volume that survives restarts. Deployment
• Confirm the persist mode matches your loss tolerance; it is sync_all by default. Durability
• Have a backup plan: stop-and-copy or an atomic volume snapshot. Never copy a live db_path. Backups

Limits & resource bounds

• Cap limits.max_message_bytes and per-queue max_queue_depth to bound memory; queue depth is unlimited by default. Limits & quotas

Operations

• Wire the gRPC health service into your liveness and readiness probes. Health checks
• Set up tracing and metrics collection. Observability
• Enable dead-letter retention, then decide a triage process; retention is off by default. Dead-letter management

Where to next