Setting up a full observatory web stack

pyobs-core and the driver-module repos give you the hardware/control side of an observatory: a fleet of modules talking to each other over XMPP (see Setting up ejabberd). That’s everything a single-telescope, script-driven setup needs. A multi-telescope or remote-operated setup usually also wants a browser-facing layer on top — and that layer lives in a handful of separate repos, each its own standalone web service with its own deployment.

This page is a map of that layer: what each service does, how it connects to your pyobs fleet, and where to go for the real install steps. It deliberately doesn’t reproduce those steps here — each repo’s own Docker Compose setup, environment variables, and configuration options are documented on its own docs site (see Affiliated projects), and a second copy of that here would just drift out of sync with it.

The services

Each entry below links straight to that repo’s own installation instructions (Docker Compose, environment variables, migrations).

pyobs-portal installation

Web backend and UI for multi-telescope task/observation queue management. A pyobs fleet talks to it by using PortalTaskArchive and PortalObservationArchive in place of the local YAML-file task archive — see Scheduling (pyobs.robotic.scheduler) for the classes and Setting up a minimal robotic observation system for a minimal robotic-mode setup you can point at a portal instead of local files.

Task editor showing target fields and a Constraints panel with Airmass, Moon Separation, and Solar Elevation constraints.
pyobs-archive installation

Webservice for an archive of astronomical images, implementing most of the Las Cumbres Observatory archive interfaces. A pyobs fleet talks to it via PyobsArchive. Can optionally restrict frame access to project members through a pyobs-portal connection.

Frame browser showing a filter sidebar and a sortable table of BIAS, DARK, SKYFLAT, and EXPOSE frames.
pyobs-web-admin installation

Web GUI for monitoring and managing the modules in a running fleet.

Dashboard showing modules grouped under Stopped and Deactivated headings, with summary tiles and per-row quick-action buttons.
pyobs-pipeline installation

Web-based monitoring and configuration for pyobs data-reduction pipelines: status, logs, retriggering reduction periods, and a guided builder for pipeline steps.

Dashboard showing two site cards with last period, next trigger, and input/output status, plus a table of recent reduction periods.
pyobs-weather installation

Weather data aggregator. A pyobs fleet talks to it via pyobs.modules.weather.Weather, pointed at the running instance’s URL.

pyobs-auth installation

Not a deployed service on its own: a shared Django/OIDC client library that pyobs-portal, pyobs-archive, pyobs-web-admin, and pyobs-pipeline each use for Keycloak-based single sign-on. You still need an actual OIDC identity provider (e.g. Keycloak) running somewhere for these apps to authenticate against — pyobs-auth is the client integration, not the identity provider. Its own docs cover adding it to a Django project, not a standalone deployment.

Suggested order

Since the four deployed web apps all depend on pyobs-auth for login, and pyobs-core’s own modules are typically pointed at portal/archive/weather rather than the other way around, it’s usually least friction to bring things up identity-provider-first: your OIDC provider, then the web apps that authenticate against it, then finally reconfigure your pyobs module fleet (task archive, frame archive, weather module) to point at the running services instead of local files.

Where to go next

The installation links above land you in each service’s own docs site; from there its configuration and architecture pages cover environment variables and how it fits into the rest of the fleet in more detail than belongs here. The full list of affiliated projects, with links to each one’s docs home, is at Affiliated projects.