UnyPort Manual
This page is the practical entry point for operators using UnyPort in day-to-day work. It focuses on the visible workflow from first login to supervised actions.
Normal operator path
The usual path is:
- Open the
UnyPortURL - Sign in with a local or OAuth-backed account
- Confirm the detected host role
- Read dashboard metrics and restart history
- Move to hypervisor, network, storage or security pages
- Open a proxied internal app when needed
- Update profile or admin settings only if the role allows it
Open portal
-> Authenticate
-> Read host role
-> Check CPU / memory / network
-> Inspect Xen or LBU context
-> Review logs or security
-> Escalate through TRINITY or UnyDesk if needed
Before first use
Prepare a few pieces of information:
- The correct URL or reverse proxy entry point
- A local user or configured OAuth provider
- The expected host type: Dom0, DomU, container or Alpine host
- Whether an internal proxied app such as
ttydshould be available
What the portal can expose
Depending on configuration and host role, UnyPort can expose:
- Dashboard summaries
- Live CPU, memory and network data
- Disk state and LBU persistence status
- OpenRC services and selected logs
- Security checks and listener exposure
- Xen hypervisor and domain data on Dom0
- Operator profile, SSH key and branding settings
When the path becomes more technical
The workflow becomes more operational when the operator needs to:
- Compare the running Alpine or kernel version with current
TRINITYboot tags - Inspect a Dom0 and its active domains
- Verify whether LBU changes are committed
- Review crashed services
- Open a proxied terminal app through
/proxy/<name>/
The next pages act as the structured manual for those tasks.