# FAQ > Frequently asked questions about psLens: supported PeopleTools versions, security, deployment, and commercial terms. --- Site [llms.txt](/llms.txt) --- ## Frequently Asked Questions Quick answers to the questions we get most often. If your question is not here, reach out through the [contact page](/contact/). --- ## Getting Started ### Do I need App Designer to use psLens? No. psLens is an alternative to opening App Designer for research, auditing, and monitoring work. Your developers still use App Designer for building and modifying PeopleSoft objects. psLens is for everything else (search, security audits, process monitoring, IB monitoring, reporting). ### How long does setup take? A typical first-time install is under an hour of real work: [install the SWS framework](https://sws.books.cedarhillsgroup.com/docs/installation/installation/) in your PeopleSoft environment, deploy your psLens instance, point it at your SWS endpoint, and log in. The [installation guide](/docs/getting-started/installation/) walks through every step with Docker and bare-metal examples. ### Can I try psLens without installing the SWS framework? No. SWS is how psLens reaches PeopleSoft; there is no alternate data path. The [demo](/contact/) is the right way to see it running against a live environment before you commit to an install. SWS documentation lives at [sws.books.cedarhillsgroup.com](https://sws.books.cedarhillsgroup.com/docs/). ### Which PeopleTools versions are supported? psLens relies on standard PeopleTools metadata tables (`PSRECDEFN`, `PSPNLDEFN`, `PSCLASSDEFN`, process scheduler tables, Integration Broker tables) that have been stable for many PeopleTools releases. If you are on a currently supported PeopleTools release, psLens will run against it. Ask on the demo call if you have a specific version in mind. ### What is the technology stack used by psLens? A single Go binary. Rendering happens server-side and updates are pushed to the browser as HTML fragments over Server-Sent Events using [Datastar](https://data-star.dev). There is no React or Angular bundle to ship, and nothing from PeopleSoft is cached in the browser. See the [Architecture Overview](/docs/getting-started/architecture/) for details. --- ## Security ### Is psLens really read-only? Yes. psLens does not have a code path that writes to PeopleSoft. It issues read queries through the SWS framework, which itself only answers queries against a whitelisted set of metadata tables. See the [Security & Trust](/docs/trust/) page for the full story. ### What permissions does the SWS service account need in PeopleSoft? Read access to the whitelisted PeopleTools metadata tables. No write access. No access to transactional business tables. The whitelist ships with psLens and SWS; you can review and narrow it before you approve it in your environment. ### Does psLens store a copy of our PeopleSoft data? No. psLens stores two things: alert history (short retention, meant to show what is currently wrong) and report output (kept for 90 days so you can review past audit findings). It does not copy employee records, financial transactions, HR data, or any other business data into its own storage. There can be some temporary caching in memory on the server to facilitate rendering and alert/report generation, but this is short-lived and does not persist beyond the lifetime of the request or the retention period for alerts and reports. ### Where does the data live? Inside your dedicated psLens instance. Every customer gets their own isolated deployment; there is no shared multi-tenant backend. See [Security & Trust](/docs/trust/) for deployment isolation details. ### Does psLens cache or store PeopleSoft data in my web browser? No. psLens renders pages on the server and streams them as HTML fragments. The browser displays the HTML; it does not write metadata or credentials to LocalStorage, SessionStorage, or IndexedDB. As soon as the browser tab is closed, the data is cleared from client memory. --- ## Deployment ### Can I host psLens inside my own infrastructure? Yes. The default is a dedicated instance hosted on [fly.io](https://fly.io), but psLens ships as a Go binary and a Docker image, so you can run it in your own cloud account, Kubernetes cluster, or on a Linux VM. The [installation guide](/docs/getting-started/installation/) covers Docker, systemd, and air-gapped setups. ### Does psLens work in an air-gapped environment? Yes. The [installation docs](/docs/getting-started/installation/) include instructions for environments with no outbound internet access. psLens does not phone home and does not require outbound connectivity at runtime beyond reaching your SWS endpoint. ### How do upgrades work? Upgrades replace the psLens binary or Docker image. Configuration stays in `config.yaml` or environment variables. Alert and report history is preserved across upgrades. See the upgrade section of the [installation guide](/docs/getting-started/installation/). --- ## Day-to-Day Use ### Can psLens connect to multiple PeopleSoft environments? Yes. A single psLens instance can be configured to connect to multiple databases (DEV, TEST, PROD). The database selector appears on every search and report page. See [configuration](/docs/getting-started/configuration/). ### Can I compare objects across environments? Yes. The [Project Compare](/docs/reports/objects/) report compares project items across databases, useful after migrations to confirm what actually landed where. ### Can I share or export what I find? Yes. Every PS object detail page and every completed report can be exported as Markdown. The output is plain text that works in wikis, PRs, documentation sites, or as input to AI tools. See the [AI enablement use case](/docs/use-cases/ai-enablement/). --- ## Commercial ### How is psLens sold? psLens is sold as a flat-rate subscription of **$500/month** with unlimited seats/users and unlimited PeopleSoft environments, plus a one-time setup fee: **$2,500** for CHG-managed deployments or **$4,500** for self-hosted. What each fee covers, and why self-hosting costs more, is on the [pricing page](/pricing/). *Note: Standard pricing applies to single-organization end-users only. It does not apply to hosting providers, managed service providers (MSPs), or organizations that host and manage PeopleSoft databases for multiple third-party clients. Contact us for multi-client custom pricing.* ### What kind of support is included? Setup assistance is included with every deployment. Ongoing support terms are part of the agreement and vary by customer. We will walk through it on the demo call. ### Who builds psLens? psLens is built by [Cedar Hills Group](https://www.cedarhillsgroup.com), a PeopleSoft consultancy. The same team that built the SWS framework builds psLens. --- ## Code & Supply Chain ### Can we review the source code? psLens is closed-source, but Cedar Hills Group offers a read-only source review under NDA as part of procurement. See [Code & Supply Chain](/docs/trust/code-and-supply-chain/) for details. ### Is the code scanned for vulnerabilities? Yes. We use `govulncheck` in our continuous integration pipeline to detect known Go package vulnerabilities on every build and run daily scans. Dependabot is enabled to monitor and automatically raise pull requests for dependency updates (Go modules, GitHub Actions, and Docker base images). See [Code & Supply Chain](/docs/trust/code-and-supply-chain/#4-dependency-management). ### How do you handle vulnerability reports? Email `security@cedarhillsgroup.com`. We acknowledge within one business day and coordinate disclosure with the reporter. See [Code & Supply Chain → Vulnerability Disclosure](/docs/trust/code-and-supply-chain/#5-vulnerability-disclosure-and-patching). --- ## Authentication & Access ### Can we use our existing SSO? Yes. psLens natively supports OpenID Connect (OIDC) Single Sign-On (Microsoft Entra ID, Okta, Keycloak, Auth0, Google Workspace) configured directly in `config.yaml`. Alternatively, you can front psLens with a reverse proxy that handles SSO (Cloudflare Access, oauth2-proxy, Pomerium, Tailscale). See [Authentication & Access](/docs/trust/authentication-and-access/). ### Does psLens have role-based access control? No, by design. Because psLens is read-only and the query surface is whitelisted on the PeopleSoft side, the access boundary is "who can log in to psLens at all," not "what role do they have inside it." Per-user authorization is enforced at the reverse-proxy / IdP layer if you need it. This is something we are exploring in a future release, pending customer feedback. ### How are passwords stored? No end-user passwords. psLens uses email magic-link, native OIDC, or reverse-proxy SSO. The only password-shaped secret psLens holds is the SWS service-account credential, encrypted at rest with AES-256-GCM. See [Data Handling & Logging → Encryption](/docs/trust/data-and-logging/#4-encryption). ### Can we require MFA? Yes. Enforce MFA at the IdP layer with native OIDC or reverse-proxy SSO. Magic-link auth on its own is single-factor. --- ## Audit & Logging ### Where do logs go? psLens writes structured logs to stderr only. Your container runtime decides what happens next: Docker logging driver, systemd journal, fly.io log stream, or Kubernetes log shipper, then on to your SIEM. ### Does psLens retain logs? No. psLens does not manage log retention. Whatever your container runtime or log aggregator does is what you get. This is intentional, so your existing log-retention SLA covers psLens without us getting in the way. --- ## Compliance ### Are you SOC 2 certified? Not yet. Certification is on the roadmap. In the interim, [Compliance & Vendor](/docs/trust/compliance-and-vendor/) maps the relevant Trust Service Criteria to current controls, and we complete SIG / CAIQ questionnaires in detail. ### Where does our data physically live? In your dedicated psLens instance. Managed deployments run in the fly.io region you choose at provisioning. Self-hosted: wherever you run the container. There is no shared multi-tenant backend, so there is no other location for data to exist. ### Who are your sub-processors? Depends on your deployment mode. For managed deployments: fly.io (hosting) and the SMTP provider for magic-link auth (if enabled). GHCR is touched only at `docker pull` time, not at runtime. Self-hosters have none of the above. See [Compliance & Vendor → Sub-Processors](/docs/trust/compliance-and-vendor/#sub-processors). ### What happens if Cedar Hills Group goes away? You keep the Docker image you're running, and self-hosting works without any Cedar Hills Group infrastructure. All state is in the per-customer `/data` volume, portable to your own infrastructure on demand. See [Compliance & Vendor → Business Continuity](/docs/trust/compliance-and-vendor/#7-business-continuity-what-happens-if-cedar-hills-group-goes-away). Pending customer feedback, we can potentially look at a code escrow of the GitHub source code. --- ## Operations ### What load does psLens put on my PeopleSoft environment? Small, and you control all of it. There are three sources of queries: - **Browsing and search** run on demand when someone uses the UI. Each page issues a handful of paged queries against PeopleTools metadata tables, comparable to a person opening a page in PIA. There is no background crawler or sync job; psLens fetches what is on screen and nothing else. - **Alert checks** are the only recurring traffic. They run on a configurable interval (default every 5 minutes), and each check is a small number of bounded queries. You can change the interval per database, disable individual checks, or turn alerting off entirely for an environment. See [configuration](/docs/getting-started/configuration/). - **Reports** run only when someone starts one. All of this arrives through the Integration Broker REST endpoint as ordinary service operation requests, so it appears in your existing IB monitoring like any other integration. psLens never opens a connection to the database itself. ### What exactly does SWS install in my PeopleSoft environment? A standard App Designer project (`CHG_PSLENS`), migrated dev-first through your normal change process: 46 objects under the `CHG_` prefix, 1 record (the whitelist table), two service operations, and one API role/permission list. [What SWS Installs in PeopleSoft](/docs/trust/what-sws-installs/) lists the full breakdown for the admin, DBA, or security reviewer who has to approve it. ### What's the backup procedure? Tar `/data/nats` and `/data/projects` nightly; back up `PSLENS_MASTER_KEY` separately and out-of-band. Restore is "untar into a fresh volume and start the container." See [Deployment & Operations → Backup](/docs/trust/deployment-and-operations/#4-backup-and-restore). There is no critical data stored in the application and technically, all the data could be left behind in the event of a failure. The backup procedure is primarily for convenience and peace of mind, not a strict requirement for disaster recovery. ### How do I upgrade? Pin production to `vMAJOR.MINOR`, then `docker compose pull && docker compose up -d`. The data volume survives the restart. Roll back by pinning to the prior patch tag. See [Deployment & Operations → Upgrades](/docs/trust/deployment-and-operations/#7-upgrades-and-rollback). ### What's the resource footprint? Small. 1 vCPU and 512 MB RAM as a minimum, 1 GB disk for `/data`. psLens is a single Go process; scaling is vertical. See [Deployment & Operations → Sizing](/docs/trust/deployment-and-operations/#3-sizing). ### What network egress does psLens need? HTTPS to your SWS endpoint, and SMTPS to your mail server only if magic-link auth is enabled. Nothing else: no telemetry, no update checks, no callback to Cedar Hills Group. Egress filtering is straightforward. ### Does psLens have a Prometheus endpoint? Not today. `GET /healthz` covers liveness; structured slog covers everything else. A native `/metrics` endpoint is on the roadmap.