How it works

The architecture, end to end

ip·Solis is one repository: a web app, a Celery worker that embeds the PowerShell 7 runtime, and Beat — with Redis and Postgres behind them. Most teams are in production within a working day.

A small, opinionated stack

The web app and a Celery worker that embeds the PowerShell 7 runtime, plus Beat. Redis as the broker, Postgres for storage. Reverse proxy of choice.

  • Web app — FastAPI (Python 3.12), server-rendered admin and portal with HTMX + Jinja2 + Tailwind
  • Celery worker — orchestrates runbook execution and async jobs, and runs the PowerShell 7 steps in-process
  • PowerShell 7 — runs script steps natively inside the worker, on Linux, with Kerberos / GSSAPI
  • Beat — schedules cron-driven runbooks and the daily cost-threshold check
  • Redis — Celery broker and RedBeat schedule lock
  • Flower — for queue inspection in development and incident response
Reverse proxyIngress · TLS
FastAPIWeb app
Celery + PowerShell 7Runbook engine
BeatScheduler
RedisBroker
PostgreSQLStorage

Flower · Queue inspection (dev)

PowerShell 7 worker, on Linux

Native, not a wrapper. Use the modules and idioms you already know.

  • Kerberos / GSSAPI authentication for SCCM
  • PSGallery installs and manual zip upload at runtime — via the PS module store, persisted in the Docker volume
  • Per-step timeout, retry and log capture on standalone runbooks
  • Live step-log streaming on standalone runbooks (captured per step on order provisioning)

Celery + Beat for scheduling

Standard cron expressions. Overlap protection so a standalone runbook does not start a new run while its previous one is still active, and pool reservations that never hand the same asset to two orders.

  • Cron schedules per runbook
  • Timezone-aware scheduling for the daily threshold checks
  • Skip-if-running guard on standalone runbooks
  • Access-drift reconciliation on a schedule — detect or auto-remediate AD changes
  • Renewal, certification and attestation reminders as scheduled Beat tasks
  • Flower UI for live inspection

Joiner, mover, leaver — SCIM 2.0 and HR

One identity lifecycle. Your IdP or HRIS drives it; ip·Solis provisions, reconciles and revokes.

  1. 01Joiner: a new user matches your assignment rules — the mapped bundles are ordered automatically.
  2. 02Mover: an attribute change re-evaluates the rules; new entitlements are added, lost ones optionally revoked.
  3. 03Leaver: active=false via /scim/v2/Users or /hr/leaver revokes every asset the user holds.
  4. 04Each asset runs its deprovision runbook; rule-provisioned access can be reclaimed automatically.
  5. 05Every step is recorded in the append-only audit log with full attribution.

The order state machine

Every order moves through this machine. Failures and revocations are first-class — never silent.

  1. Pending Approval

    Awaiting manager approval.

  2. Scheduled

    Approved and queued for the worker.

  3. Processing

    Runbook steps executing.

  4. Provisioned

    The asset is live for the user.

  5. Failed

    A critical step failed. Review the log.

  6. Rejected

    A manager declined the request.

  7. Cancelled

    Cancelled before processing.

  8. Revoked

    Access revoked and the asset reclaimed.

  9. Expired

    Validity ended; the asset is reclaimed.

The architecture, end to end — ip·Solis