You pick a region. Loghound does the rest, one named step at a time, so a failure tells you which step it failed on rather than that “setup failed”.
Figure 1 — provisioning. The configset order is load-bearing: reversed, the core reloads against a solrconfig referring to field types the old schema does not define, and the reload fails.
An Opensolr index name is unique across the whole platform, not just within your account, and it is permanent once created. A hardcoded loghound_hits would therefore have worked for exactly one person. Both cores share one eight-character hexadecimal installation id:
loghound_9f3c17ab_hits loghound_9f3c17ab_sessions
If either name is already taken, the whole pair is retried with a fresh id — a mismatched pair is confusing to find in an account holding hundreds of indexes — and any index the failed attempt created is deleted before the retry, so a collision cannot leave orphans on an account you are billed for. After five attempts it gives up with a clear error rather than looping.
Both are read from the configuration, and there is no setting, prompt or environment variable that lets you supply one. The installation id is generated once and never rotated: it is part of the identity of the two indexes, so changing it would orphan the data rather than rename it.
One exception to the retry, and it depends on who holds the colliding name. If your own account already holds it — which is what a previous attempt of your own leaves behind — the index is reused rather than abandoned. Loghound asks Opensolr which indexes your account holds before deciding, and if it cannot get an answer it stops and says so rather than guessing, because guessing wrong in that direction leaves you paying for an index nothing points at.
The two configsets shipped in the repository under solr/hits/conf/ and solr/sessions/conf/ are real and are exactly what gets pushed, so everything the schema page describes is what is running. You do not install them by hand.
They are Solr 9.x, and they deliberately load no contrib jars and define no streaming, SQL, export, replication, extraction, terms or browse handlers. Each removal is annotated in the configset with what it would have handed an attacker.
It can create, reconfigure and delete every index on the account. Loghound reads it with terminal echo off, never prints it back — not even masked, because a masked key in a scrollback is still a key in a scrollback — never writes it to the install log, and strips it out of any error message the platform echoes back. It lives in config/loghound.php, mode 0640, in a 0700 directory the web server user cannot reach.
The connection details of the node your indexes landed on are written for you from what the platform returns. You never type them, and there is no form, POST action or environment variable that will accept them from you.
If you already run Loghound somewhere, consider joining the pair you already have instead of creating two more — and read the plan index limit either way, because it is checked before the first create.