Settings and management
Application configuration, the encrypted secrets keyring, and the management console with instance identity, the application log and lifecycle controls.
Three pages administer the application itself rather than the generators running in it: the Settings page for its configuration, the Secrets page for the credentials that configuration refers to, and the Management page for what the process is doing.
Settings
The Settings page edits the application configuration — the same parameters eventum.yml holds, written back to that file on save.
| Section | Covers |
|---|---|
| Server | How the instance is reached — API, web interface, TLS, authentication, MCP |
| Generation | The defaults every generator inherits |
| Paths | Where generators, logs, the startup file and the keyring live |
| Logging | Level, the level of third-party libraries, format, rotation |
A section holding unsaved edits is marked in the rail, so changes spread across several of them stay visible from wherever you are.
Batch size and queue depths decide how much memory generation holds at once. The Generation section works that figure out for you: give it an assumed event size and it reports what full queues will occupy for one generator. Limit memory of events queue bounds it directly: Maximum event bytes caps what the events queue holds whatever the batches in it weigh.
The Save button appears in the page header once anything is edited and asks for confirmation first. These parameters are read when the application starts, so applying them triggers the same restart the Management page offers, and the interface is briefly unavailable.
Secrets
The Secrets page manages the encrypted keyring, the same one eventum-keyring manages from the terminal. A secret is referenced from any configuration as ${secrets.name} and resolved when a generator loads.
Values stay masked until asked for. Secrets are added, edited and removed in place, and a new one is available to generator configurations immediately, with no restart.
Renaming and removing a secret both state what refers to it first. A rename carries every referrer over to the new name: the ${secrets.name} token is rewritten in the configuration of each project reading it, and a connected repository authenticating with the secret is repointed. A configuration is rewritten as text, so its comments and formatting stay as they were written; a generator already running holds the configuration it loaded and reads the new name the next time it starts. A removal carries nothing over — both kinds keep the name and stop working until a secret of that name exists again.
A rename is refused when a repository already authenticates with the new name, and the repositories holding it are named. The keyring holds one value per name, so the repository left on that name would otherwise start authenticating with the value that just moved under it — the credential of one host reaching another.
Removing a secret is irreversible. Any configuration referring to it fails to load until a secret of the same name exists again, and a repository authenticating with it stops answering.
Management
The cards at the top identify the instance and the machine under it, and link through to Monitoring for the history behind the load.
The Application card also reports whether the GIL is enabled. Generators run on threads, so the free-threaded build is what lets them run in parallel, and on that build the GIL is normally disabled. It can be enabled back after the application starts — by the PYTHON_GIL=1 environment variable, by the -X gil=1 interpreter option, or by an extension module without free-threading support that a plugin imports. Generators keep running, but no longer in parallel, so the row reports that state as a warning. On a standard build the GIL is always enabled and the row is neutral.
The Instance logs panel holds the log of the application itself, split into the channels it writes:
| Channel | Contents |
|---|---|
| Main | The application core — configuration loading, which generators were started, and which of them refused to |
| Server | The API and the HTTP server |
| Access | The requests the server served |
| MCP | The MCP server, when it is mounted |
A single generator's own log is on its instance page.
Danger zone
The Restart button stops the whole application and starts it again from eventum.yml and startup.yml, without ending the process — what SIGHUP does, and the way a change made to either file outside Studio is picked up. The server stops with everything else, so the interface is unavailable for a moment.
The Stop button shuts the generators down gracefully and ends the process.
The Stop button ends the whole Eventum process, including the interface you are using. Starting it again means going back to the terminal and running eventum run -c eventum.yml.