IRIS Control Center

A focused, developer-friendly management console for InterSystems IRIS.

Built for the 2026 InterSystems Programming Contest Build Your Own Management Portal.

Contest task / idea: Build Your Own Management Portal — manage web apps and explore REST APIs

Watch the demo

Watch the 90-second IRIS Control Center demo on YouTube — Discover → understand → exercise → diagnose.

This captioned screenshot walkthrough uses genuine IRIS Community 2026.1 runtime evidence captured on 23 September 2026. It shows REST service discovery, service metadata, OpenAPI exploration and a successful /health GET. The video is unlisted and viewable by anyone with the link. At the time of recording, Windows PowerShell execution was unverified. It has since passed on Windows Server 2022 in Windows PowerShell 5.1 and PowerShell 7 against a disposable Linux-hosted IRIS container; Windows Docker Desktop installation remains unverified. See release evidence.

Why it exists

IRIS Control Center makes REST service discovery and API exploration faster and clearer than moving between multiple management screens. The contest release focuses on managing awareness of web apps and exploring REST APIs: discover what is available, understand its contract, and safely exercise read-only operations from one screen.

Current capabilities

• Discover REST-enabled applications through the native IRIS REST application catalogue.
• Normalize generated and manually configured web applications into a searchable catalogue.
• Filter services by name, namespace and web application.
• Inspect namespace, dispatch class, required resource and OpenAPI/Swagger metadata.
• Browse OpenAPI operations grouped by their advertised paths.
• Execute GET operations from the integrated request workbench, including path and query parameters, using the current authenticated browser session.
• Display HTTP status and formatted JSON/text responses inline.
• Keep mutating POST/PUT/PATCH/DELETE operations inspect-only by design for the contest release.
• Restrict request execution to discovered local IRIS web applications.
• Provide a reproducible IRIS Community 2026.1 container build with automated ObjectScript import and application setup.

For contest judges

Three-minute evaluation path: Discover → understand → exercise → diagnose.

1. Start from a clean checkout with docker compose up --build.
2. Open the Control Center and select a REST service discovered directly from IRIS.
3. Inspect its namespace, dispatch class, web-application metadata and advertised OpenAPI contract in one place.
4. Choose a read-only GET operation, supply any required parameters and execute it against the selected local IRIS application.
5. Review the HTTP status, timing and formatted response. Mutating operations remain visible for API understanding but deliberately cannot be executed from the contest UI.

Evidence against the judging criteria

Verified release evidence

The contest candidate was validated from an anonymous public checkout against a pinned IRIS Community 2026.1 container. Runtime acceptance passed all ten smoke/security checks plus real Chromium tests covering a 12-service catalogue, filtering, keyboard selection, live IRIS metadata, genuine first-party OpenAPI exploration and a successful /health GET through the production request proxy. Static checks also passed. Exact revisions, workflow runs, image digests and retained evidence are recorded in https://github.com/mrtandmilo/iris-control-center/blob/main/docs/RELEASE_EVIDENCE.md.

For the shortest reviewer walkthrough, use https://github.com/mrtandmilo/iris-control-center/blob/main/docs/DEMO.md. The deliberate GET-only execution boundary is a safety decision, not an incomplete HTTP client: mutating methods can be inspected while execution stays constrained to discovered local IRIS applications.

Quick start

Prerequisites: Docker with Compose support and access to the InterSystems IRIS Community image configured by this repository.

docker compose up --build

After IRIS is healthy, open:

http://localhost:52773/iris-control-center/

For the repository’s default Docker Compose configuration, authenticate with:

Username: _SYSTEM
Password: SYS

If you set IRIS_PASSWORD before starting Compose, use that password instead. The browser’s HTTP Basic Authentication prompt is expected: the UI and API are protected by IRIS authentication. If the page does not load, first run docker compose ps and confirm the iris service reports healthy, then inspect docker compose logs iris.

The UI and API are protected by IRIS password authentication. The API is mounted separately at /iris-control-center/api. Credentials and authorization headers are not stored by the browser application.

Windows / PowerShell quick validation

The application itself runs in Docker and is cross-platform; the Bash scripts under scripts/ are maintainer/CI release tooling and are not required to use the demo. On Windows, after docker compose up --build -d, use PowerShell:

$env:IRIS_PASSWORD = 'SYS'   # use your override instead if you changed it
.\scripts\smoke-test.ps1

If you supplied a custom IRIS_PASSWORD, replace SYS above. The PowerShell smoke test verifies the health contract and live service-discovery response, then prints the browser URL. Then open http://localhost:52773/iris-control-center/ in a browser and use the same credentials.

Architecture

The application has three deliberately small layers:

1. IRIS discovery adapter — uses the native %REST.API.GetAllWebRESTApps() interface and normalizes %REST.Application metadata for generated and manually configured REST applications.
2. IRIS REST backend — exposes health, catalogue, OpenAPI and safe request-execution endpoints to the authenticated UI.
3. Browser Control Center — searchable service catalogue, OpenAPI viewer and safe GET request workbench.

The UI and API have separate IRIS web applications so routing and security responsibilities remain explicit, while both use the same IRIS authentication boundary. See https://github.com/mrtandmilo/iris-control-center/blob/main/docs/ARCHITECTURE.md for the component diagram, request flow and trust-boundary rationale.

Security principles

• No credentials committed to the repository.
• No passwords or authorization headers persisted in browser storage.
• IRIS remains responsible for authentication and authorization.
• Discovery is read-only by default.
• The interactive workbench executes GET operations only; mutating methods remain visible for documentation but cannot be launched from the UI.
• Request execution is restricted to the selected service’s local web-application path rather than accepting an arbitrary remote host.
• Traversal attempts and unknown-service requests are rejected by the backend.

Contest-release limitations

The deliberately narrow release scope keeps the explorer useful without turning it into a second unrestricted administration console:

• Interactive execution is limited to GET. POST, PUT, PATCH and DELETE operations can be inspected but not executed.
• The explorer only executes requests against REST web applications discovered on the same IRIS instance; arbitrary external URLs are not accepted.
• OpenAPI exploration depends on a discovered service advertising a usable OpenAPI/Swagger definition. Services without one still appear in the catalogue and expose their available IRIS metadata.
• The supplied and continuously tested deployment target is the pinned IRIS Community 2026.1 container configuration. Other IRIS editions or releases are not claimed as validated by this contest build.
• The project does not replace the full InterSystems Management Portal; its contest scope is REST service discovery, contract exploration and safe read-only request execution.

Validation and contest preparation

The release is continuously validated from a clean disposable IRIS instance. The release-validation workflow removes the persistent test volume, pulls the pinned IRIS Community 2026.1 image, performs a no-cache build, compiles all ObjectScript classes, waits for container health and runs the application acceptance suite.

The clean runtime acceptance suite verifies authenticated UI delivery, browser assets, API authentication, health, native service discovery, OpenAPI input validation, request-proxy validation, traversal protection and unknown-service isolation.

• https://github.com/mrtandmilo/iris-control-center/blob/main/docs/TESTING.md defines the clean-build, API, browser and security release gates.
• https://github.com/mrtandmilo/iris-control-center/blob/main/docs/ARCHITECTURE.md documents application boundaries and security decisions.
• https://github.com/mrtandmilo/iris-control-center/blob/main/docs/DEMO.md provides the demo video, a three-minute reviewer walkthrough and evidence references. Recording and evidence checks are in https://github.com/mrtandmilo/iris-control-center/blob/main/docs/RELEASE_PROCESS.md.
• https://github.com/mrtandmilo/iris-control-center/blob/main/docs/CONTEST_SUBMISSION.md contains the evaluator-focused project summary, demo flow and final submission gate.
• https://github.com/mrtandmilo/iris-control-center/blob/main/docs/ROADMAP.md tracks final contest packaging work.

Development status

The core contest workflow is implemented and runtime-tested against the pinned InterSystems IRIS Community 2026.1 container: installation, authentication, service discovery, OpenAPI inspection, safe read-only request execution and backend security contracts. Anonymous public-checkout installation, clean release validation and real-browser evidence have passed; see https://github.com/mrtandmilo/iris-control-center/blob/main/docs/RELEASE_EVIDENCE.md for the exact tested revision. The contest entry has been submitted and accepted. This repository remains the public, continuously improvable source during the voting period.

Contest

The official contest runs September 14–October 4, 2026, but new submissions close September 27, 2026 at 23:59 EST. Community voting runs September 28–October 4, and submitted applications may continue to be improved during voting.

The contest scores Complexity, Clarity of Instructions, Developer Experience, Applicability and Usability. IRIS Control Center uses Docker container deployment and is listed as a Newcomer entry on the official contest page. Other technology bonuses are not claimed unless their qualifying deliverable is actually present.

Official references:

• Contest page
• Developer Community announcement and task
• Technology bonuses

License

MIT — see LICENSE.