Settings¶

The Settings screen holds the configuration of the instance. It needs an administrator account. The screen has five sections.

General¶

Site name: The name that the browser tab and the header show.
Licensed to: The name of the licence holder.
Public URL: The public address of this instance. Midair builds the webhook addresses and the MCP address from it, and Horizon calls back to it.
Logo URL: The address of the logo.

Features¶

Four switches enable or disable the top-level sections: Vision, Monitoring, Testing and Analysis.

A disabled section disappears from the sidebar, and its screens answer Not Found.

These four are not the licence features of Users, teams and access. They are a choice about what this instance shows.

Access¶

The switch Public instance decides who can read without an account. It is off by default.

Off (private): Midair and the Bublik beside it are behind the sign-in. A person without an account sees only the sign-in page. A link to a Bublik page sends them to the sign-in, and back to that page after it.
On (public): A visitor without an account reads what a viewer of every project reads: the projects, the test runs, the analyses, their results, logs, charts and comments, in Midair and in Bublik. A visitor does not see the users, the teams, the nodes, the monitored devices, the credentials or the settings, and cannot start, change or delete anything. The header shows Sign in instead of the account menu.

The switch takes effect at once, in Midair and in Bublik.

Setup¶

Run setup again opens the setup wizard. Use it to go back over the questions that the wizard asked at the first sign-in. See Getting started.

Integrations¶

Each integration is a card. The card says whether the integration is configured, and a click opens its fields.

Releases

The portal that the Distributions marketplaces list, and the credential that Midair asks with. See Distributions.

Bublik

Where the test logs are published and browsed. The fields name the Bublik UI address, the SSH account of the log server, and the incoming directory. Midair derives the incoming directory from the environment variables when the override field is empty. See Testing.

Midair keeps the Bublik installed with it in step with itself, once a minute, over the same SSH account:

Each Midair user with an e-mail address has a Bublik account with that address and the same password. Administrators are Bublik administrators. A user that is deactivated or deleted in Midair is deactivated in Bublik. Bublik accounts that Midair did not make stay as they are. On a shared instance only administrators get a Bublik account, and only they may open Bublik.
Each Midair project has a Bublik project of the same name, and the runs of the project are imported into it.
Each such Bublik project has the configurations per_conf, references (the log server and the repositories of the project) and a report configuration midair with a chart for each test that reports measurements. When a person activates a version of their own of one of these configurations in Bublik, Midair leaves that configuration alone.

The card shows when the last synchronization ran and what it changed.

AI

The provider for the log analysis, the reviews and the Vision lines. See AI providers.

E-mail

The mail server. Midair sends the one-time sign-in codes and the comment notifications through it.

Delta

The monitoring agent. Two fields: the path to the agent repository on this server, and the address that the agent reports to. The report address must be reachable from the devices, so it is not localhost and not the port of the user interface. An empty field falls back to the public URL. See Monitoring.

Webhooks

The incoming hooks that start a template from outside. See Continuous integration.

Google Calendar

Mirrors the planned runs into a calendar.

MCP

The endpoint for an AI assistant. See MCP endpoint.

Credentials

The secret store: the passwords and the SSH keys that the nodes and the repositories use. See Credentials.

AI providers¶

Midair can reach an AI model in four ways. Two of them are the HTTP APIs of the vendors, billed per token against a key. The other two are the command-line tools of the assistants, which answer out of the subscription that they were signed in with.

Provider	How it answers
`claude`	The Anthropic API, with an API key.
`openai`	The OpenAI API, with an API key.
`claude-cli`	The Claude Code command-line tool.
`codex-cli`	The Codex command-line tool.

The screen also holds the model name for each API.

Signing in the command-line tools¶

The two tools sign in differently, because the vendors made two different choices about where the browser has to be.

Codex signs in from anywhere. codex login --device-auth prints a link and a one-time code, and it returns when somebody approves it in a browser on any machine. The server drives that itself: the screen shows the link and the code, and the administrator finishes it on whatever device they are sitting at.

Claude cannot be driven that way. Its sign-in opens a browser on the host that runs it, and on a server that is nobody’s browser. So the token is made where a browser already is. Run claude setup-token on the machine of the administrator, and paste the result into the credential store.

Either tool also accepts a plain API key, and either may already be signed in by hand on the host. The screen asks the tool about itself rather than reading the settings, because what the tool believes is the only answer that predicts whether the next run works.

System update¶

Update this instance asks the server to update itself. The server stops answering while it restarts, and the screen waits for it to come back. Reload the page to pick up the new version.