The goal was not another public dashboard
RyanOS is an internal launch surface for a homelab: a place to orient quickly, move between trusted tools, and keep operational links in one recognizable interface. The target is not a general-purpose SaaS portal. It is a LAN-scoped control surface for an environment that includes agent runtimes, model gateways, development tools, network administration, productivity services, storage, and everyday reference links.
That distinction shaped the deployment. Internal publishing still needs the engineering discipline of a real application: a repeatable source of truth, service ownership, recoverable configuration, safe browser access, and verification from the endpoint a user actually opens. But it must not turn an internal convenience page into a repository of credentials, private chat history, tokens, or raw infrastructure logs.
What RyanOS does
The restored RyanOS launcher is a visual navigation layer. It groups bookmarked services into sections such as Home, AI Live, Favorites, Agent OS, AI Agents, AI Gateway, NAS, Network, Productivity, Development, E-mail, Password Manager, Banking, Retail, Navigation, and Communications. Each section presents recognizable launch tiles rather than asking an operator to remember every port, hostname, and login route.
The interface also provides favorites and lightweight tile-health indicators. Favorites are intentionally a browser-local convenience: they improve day-to-day navigation without making a central server responsible for personal bookmarks. Health hints are navigation signals, not an authoritative monitoring system; critical service diagnosis still belongs to the service logs, systemd state, and dedicated operational dashboard.
Why the newest release did not look like the old RyanOS home page
The latest RyanOS repository release is v28, an Obsidian-compatible Markdown Vault. It is useful for browsing, editing, searching, and linking Markdown content, but it is not the tile-heavy launcher expected at the root of RyanOS. Deploying v28 alone worked technically while producing the wrong user experience: the root opened directly into a Markdown workspace instead of the familiar visual home page.
The solution was to treat the two interfaces as complementary rather than competing releases. A tracked v27 AgentOS release artifact contained the visual launcher, section configuration, icons, and bookmarks. That launcher was restored as the primary RyanOS root. The v28 Vault was retained as a separate service and linked back into the launcher as a first-class Productivity tile.
Two services, two jobs
| Surface | Purpose | Port |
|---|---|---|
| RyanOS Tile Launcher | Visual sections, bookmarks, favorites, and service launch tiles | 7777 |
| RyanOS v28 Vault | Obsidian-compatible Markdown workspace, search, backlinks, and indexed files | 7778 |
This split avoids a false choice. The launcher remains fast and predictable because it serves static UI assets and configuration. The Vault can evolve as a content workspace without accidentally replacing the control-deck experience. Both are managed as enabled user services so the deployment survives reboot without relying on a manually opened terminal.
Deploying the current GitHub source safely
The deployment uses a generic directory name instead of putting a release number into the path. This prevents service files, scripts, and operational notes from becoming coupled to a specific version folder. The actual release identity is kept in a dedicated marker file, recording the source release and revision without confusing version metadata with deployment layout.
/home/ryan/RyanOS/ ├── RYANOS_RELEASE # release and source revision marker ├── launcher/ # restored tile UI and configuration ├── launcher-server.js # small static launcher server ├── apps/vault/ # v28 Vault application └── ObsidianVault/ # Markdown workspace data
Only source and intentionally managed content belong in this layout. Secrets remain in appropriate protected configuration sources. Runtime logs, transient session material, browser cookies, tokens, and private credentials are not published in documentation or copied into a convenience dashboard.
The browser-port lesson: an HTTP 200 is not enough
The first deployment used port 6666 because it was available. Server-side checks looked healthy: the process listened, the local request returned HTTP 200, and the LAN request also returned HTTP 200. Yet the browser opened an unsafe-port failure that presented as an about:blank page.
The root cause was browser policy, not a failed application. Chromium-family browsers block several ports associated with legacy protocols; 6666 is commonly blocked because of its historical IRC use. Moving the browser-facing service to port 7777 fixed the real user path. This is an important operational reminder: a service is not verified merely because curl can reach it. Verification must include the browser or client technology people actually use.
Restoring tiles and bookmarks without blindly copying a legacy system
The prior launcher had useful navigation content, but restoring it did not mean trusting every historical route unchanged. The tile configuration was reviewed and locally adjusted where internal destinations had changed. The preserved Vault received an explicit tile. Existing current operations surfaces were linked where appropriate. The aim was continuity of navigation, not an unreviewed replay of old infrastructure assumptions.
One detail from the reference interface was also clarified: an embedded Open WebUI frame initialized to about:blank by design before it loads a configured view. That behavior belongs to a lazy embedded frame, not to the RyanOS root route. The restored root is therefore the tile dashboard, while intentionally embedded components can still begin blank until they are activated.
What validation looks like
After a change, the checks are deliberately layered. First, confirm both systemd services are active. Next, confirm their listeners. Then test each HTTP endpoint locally and on the LAN address. Finally, open the browser-facing URL to confirm that browser policy, client-side JavaScript, and UI assets all behave as intended.
systemctl --user is-active ryanos-launcher.service ryanos-vault.service ss -ltnp | grep -E ':(7777|7778)' curl -fsS http://127.0.0.1:7777/health curl -fsS http://127.0.0.1:7778/
The expected result is a healthy launcher at port 7777 with the full section configuration and a separately reachable Vault at port 7778. On the visual side, the restored launcher contains 17 sections and 66 tiles, including the Vault link. Those counts are useful smoke-test expectations, not a substitute for reviewing the actual destinations when the lab changes.
How this connects to the broader operations stack
RyanOS is intentionally a launch layer, while RamLabs AI Dashboard remains the operational status and action surface. The dashboard handles fleet state, activity records, backup/readiness signals, usage telemetry, and controlled VM Files actions. Its VM Files panel now supports uploading, downloading, and confirmed file-only deletion within a constrained root. RyanOS can link to that dashboard, but it does not duplicate its audit or control logic.
This separation keeps responsibilities clear. RyanOS improves navigation and familiarity. The operational dashboard collects evidence and manages narrowly scoped actions. Agent-specific tools keep their own authentication and authority boundaries. A launcher should not become a shortcut around access controls, and a dashboard should not become a dumping ground for every bookmark.
Internal publishing principles
- Use a source of truth. Pull the current private repository and identify the exact release artifact before deploying.
- Keep version data explicit. Use a generic directory plus a release marker rather than versioned path sprawl.
- Preserve working data. Moving the root UI must not delete or overwrite the Vault workspace.
- Use browser-safe ports. Validate in a real browser, not only with command-line HTTP checks.
- Make services persistent. Use narrowly scoped user services with restart behavior and boot enablement.
- Keep secrets out. Tiles can point to authenticated services, but must never embed credentials, session material, or private tokens.
- Separate navigation from control. RyanOS launches trusted destinations; dedicated operations tools provide audited actions and health evidence.
Conclusion
Publishing RyanOS internally is less about exposing a website and more about creating a stable front door for a changing lab. The final arrangement respects both the newer Markdown-centric workspace and the proven visual launcher: the tile dashboard is where navigation starts, and the Vault is where durable notes and content live. By using a generic deployment path, explicit release marker, browser-safe port, persistent services, and real endpoint validation, the result is convenient without being fragile.