Self-hosting

Which services Mirador consists of, what it needs, which outbound connections it makes and how to back it up.

Work in progress. This documentation is not complete yet. If something is missing, write to us: support@wiestigo.com

As of 15 October 2026 · checked against Wiestigo Mirador 0.1.0

In your own data centre, Mirador runs as a set of containers, started with Podman Compose. This page gives the overview; for the set-up in detail, talk to us.

The services

Service	task
proxy	the only entry point from outside (port 8080): serves the interface, checks every request against the sign-in and routes it
rms	the model service: projects, artifacts, relationships, baselines, reviews, variants, synchronisation
identity	accounts, sign-in, memberships, tokens
frontend	the interface
mongodb	the database, as a replica set
rmm-search	full-text search (Typesense)
rmm-files	storage for attachments (S3-compatible, SeaweedFS)
rmm-document	generates documents; brings TeX Live
rmm-intelligence	the AI analysis
rmm-health	watches the other services

Only the proxy needs to be reachable from outside. It speaks HTTP; encryption with TLS is handled by a server or load balancer in front of it in your network.

The supplied podman-compose.yaml also contains mongo-express (a user interface for the database, port 8081) and, for development, publishes ports 27017, 8081, 8082, 8083, 8084 and 3000. In production, remove mongo-express and every published port except 8080.

What is needed before the first start

Configuration: a directory config.local with your settings, created as a copy of the configuration that comes with Mirador. It holds the type schema, the mapping files and rmm.properties, among others.
Secrets in a .env file: access to the database, the secrets the services use to identify themselves to each other, the keys for search and file storage, and the password of the first administrator. Without this password no administrator account is created. The template .env.example carries the placeholder xxx; where a value is missing, podman-compose.yaml falls back to a default starting with change-me. None of them may remain in production.
Access to the database is set at the first start. Changing it later means changing it in the database too.

Outbound connections

Target	what for	service
`https://license.wiestigo.com`	daily check of the licence – required; no operation without an internet connection	rms
your Jira and Jama instances	synchronisation – if set up	rms
your language model’s provider	AI analysis – if set up	rmm-intelligence

Apart from these, Mirador makes no outbound connections; the interface loads no fonts or scripts from other servers.

Setting up the language model

Whether the AI analysis uses a language model is decided by the setting rmm.intelligence.provider:

none – local analysis only, no outbound connection,
anthropic – via the Anthropic API, with an API key,
openai_compatible – any service with an OpenAI-compatible interface, including a model you run yourself; its address is required.

The configuration that comes with Mirador sets anthropic. Check the value before you enable the AI analysis. A daily token budget per user (rmm.intelligence.budget.llm.tokens.per.user.day) limits the cost; the supplied value is 0 – unlimited.

Backup and restore

Two things are backed up, in this order:

the database with mongodump – all of Mirador’s databases,
then the file storage with the attachments.

Restore in the reverse order. The search index needs no backup; it can be rebuilt from the database.

Important for the licence: the installation’s identifier is stored in the database. A restored backup keeps it; an empty database registers a new installation.

Monitoring

The System Health section of the administration shows whether all services are running – distinguishing critical ones (model service, sign-in, proxy, database) from the rest – and keeps the history for 30 days. The Change Log shows who changed what and when; changes to the settings have their own log.