This page consolidates the operational story that an IT or DBA reviewer needs in one place. It overlaps with Installation and Deployment Options; those are the how-to references, and this page is the what-to-expect security-review companion.

1. Deployment Model

• One container per customer. Each customer gets a dedicated psLens deployment: separate process, separate NATS instance, separate /data volume.
• No shared multi-tenant backend. There is no Cedar Hills Group SaaS plane that customer instances talk to. Your psLens instance talks to your PeopleSoft and (optionally) your SMTP, and that is it.
• Two hosting options:

  Mode	Operated by	Where it runs
  Managed	Cedar Hills Group	fly.io, in the region you choose at provisioning
  Self-hosted	You	Docker, docker-compose, Kubernetes, or systemd on a Linux VM. Your cloud, on-prem, or air-gapped.

The choice is reversible. You can start managed and migrate to self-hosted (or vice versa). The data volume is portable and the configuration travels.

2. Network Requirements

Inbound

Outbound

This means psLens runs cleanly behind strict egress filtering. Allow it the SWS hostname (and SMTP host if applicable) and deny everything else.

TLS termination

Cross-link: Deployment Options → TLS compares 6 patterns (native cert, Let’s Encrypt, Caddy, nginx, Traefik, Tailscale Serve). Pick the one that matches your existing edge.

3. Sizing

Recommended minimums:

For deployments handling many concurrent users or running heavy reports, scale up to 2 vCPU / 1 GB RAM. psLens is a single Go process; vertical scaling is the path, and there is no clustering model today.

4. Backup and Restore

What to back up

Suggested cadence

• Nightly tarball of /data/nats and /data/projects to your backup target.
• 14–30 day retention for daily snapshots; longer if your audit policy requires.
• Master key stored separately (so a single-system compromise can’t yield both).

Example backup script (Docker host):

#!/usr/bin/env bash
set -euo pipefail
TS=$(date -u +%Y%m%dT%H%M%SZ)
docker run --rm \
  --volumes-from pslens \
  -v "$BACKUP_DIR":/backup \
  alpine \
  tar czf "/backup/pslens-${TS}.tar.gz" /data

Restore

1. Stop the container.
2. Restore the tarball into a fresh /data volume.
3. Ensure PSLENS_MASTER_KEY matches the key that encrypted the credentials.
4. Start the container.

5. Disaster Recovery

Today’s posture:

• For self-hosted: DR is whatever your existing container DR posture is. psLens fits the same pattern as any small stateful Go service: restore the data volume, restart.
• For managed (fly.io): redeployment is fast because all state fits in one volume. Cedar Hills Group operates the deployment; RTO/RPO targets for managed deployments are disclosed during contracting.
• No multi-region replication of psLens state today. The single-customer scope makes this rarely worth the complexity, but if your contract requires it, raise it on the demo call.

If you need a higher DR posture than this, the answer is usually “self-host and use your existing DR tooling for the volume.” Cedar Hills Group can help structure that.

6. Monitoring

What ships today

• GET /healthz returns 200 OK if the process is alive. Liveness check only; no readiness signal beyond startup completion.
• Structured slog to stderr for every request and every error. Ship to your SIEM via your container runtime’s log driver.
• Startup banner in logs: version, commit SHA, build timestamp. Useful for confirming an upgrade landed.
• Connection-status UI inside psLens shows live SWS reachability for each configured database.

What doesn’t ship today

• No Prometheus /metrics endpoint. Planned. No committed date.
• No built-in alerting, in the sense of “psLens noticing it has a problem and notifying you.” That is your monitoring system’s job, fed by /healthz and the log stream.

Recommended wiring for a customer environment:

7. Upgrades and Rollback

Pin production to a vMAJOR.MINOR tag. To upgrade:

docker compose pull
docker compose up -d

The data volume survives the restart. Schema migrations on the NATS KV layer (if any) run automatically on first start of the new version.

To roll back, pin to the prior vMAJOR.MINOR.PATCH tag, docker compose up -d. Downgrade compatibility within a vMAJOR.MINOR is guaranteed; across major versions, check the release notes.

Breaking change contract: breaking changes only land in major version bumps and are called out explicitly in release notes. Patch and minor releases preserve config compatibility.

Cross-link: Deployment Options → Image Tags for the full tag-flavor table.

8. Multi-Environment Support (DEV / TEST / PROD)

A single psLens instance can be configured to connect to multiple PeopleSoft databases (DEV, TEST, PROD, demo) via entries in config.yaml. The database selector appears on every search and report page.

This is usually the right deployment shape: one psLens instance per psLens user community, configured to see every PS environment that community needs. It is rarely useful to run multiple psLens instances unless those communities have non-overlapping access requirements that need to be enforced at the network layer.

9. DBA Concerns: What psLens Does to Your PS Server

For PeopleSoft admins who need to sign off on the load profile:

The PS-side audit trail (SWS query log) captures every query psLens issues with timestamps and the SWS service-account OPRID. If psLens is misbehaving, that log shows what it actually did.

Cross-link: Installation → Whitelisting Tables for the full list and SQL.

Related

• Installation. First-time setup with copy-pasteable commands.
• Deployment Options. TLS, image distribution, configuration.
• Data Handling & Logging. What’s in /data/nats and how it’s encrypted.
• Compliance & Vendor. Sub-processors, residency, contract.