# FAQ > Frequently asked questions about psLens: supported PeopleTools versions, security, deployment, and commercial terms. --- LLMS index: [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 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](/security/) 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. ### 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](/security/) 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 myself? 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 dedicated, managed deployment per customer. For pricing and contracting details, [request a demo](/contact/) or email `chris.malek@cedarhillsgroup.com`. ### 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](/security/code-and-supply-chain/) for details. ### Is the code scanned for vulnerabilities? Dependencies are pinned in `go.mod` and reviewed by hand at each release; automated SCA (`govulncheck`, Dependabot) in CI is on the roadmap, not in place today. See [Code & Supply Chain](/security/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](/security/code-and-supply-chain/#5-vulnerability-disclosure-and-patching). --- ## Authentication & Access ### Can we use our existing SSO? Yes. Front psLens with a reverse proxy that handles SSO (Cloudflare Access, oauth2-proxy, Pomerium, Tailscale, nginx/Traefik with OIDC). This is the recommended production pattern today. Native OIDC inside psLens is on the roadmap. See [Authentication & Access](/security/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 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](/security/data-and-logging/#4-encryption). ### Can we require MFA? Yes. Enforce MFA at the IdP layer with 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](/security/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](/security/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](/security/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'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](/security/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](/security/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](/security/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.