Sun-Panel: a self-hosted navigation homepage for NAS and homelab users

The problem Sun-Panel addresses for NAS and homelab owners

A home server accumulates services: a NAS web interface, a media server, a router admin page, a few dashboards on odd ports. Bookmarks do not survive reinstalls, and typing IP addresses and port numbers gets old quickly. Sun-Panel is a navigation page that lives on the server itself and links out to everything else. The README describes it as "A server, NAS navigation panel, Homepage, Browser homepage" and lists multi-account isolation, system status display, and custom JS and CSS among its features. The target user is someone running a homelab, a Synology-style NAS, or a Raspberry Pi who wants a single page as the entry point to the rest of the machine.

The project is written as a Vue 3 front end with a Go back end, and the repository topics include docker, gin, golang, homelab, homepage, nas, navigationpage, raspberry-pi, self-hosted, startpage, synology and vue3. That combination tells you the intended deployment: a container on the same box as the services it links to, not a hosted service. The README also states there is no need to connect to an external database, which matters for anyone who does not want another moving part on a small server.

How the front end and the Go service fit together

The repository splits cleanly into a front end under src/ and a back end under service/. The Dockerfile builds the front end first with pnpm, then builds the Go binary, and finally copies both into an Alpine image. The front end is compiled to /app/web and the server binary to /app/sun-panel. At runtime the Go process serves both the static front end and the API, which is why a single container on a single port is enough.

The build uses go-bindata-assetfs to embed assets, and the Go binary is compiled with the flags -X sun-panel/global.RUNCODE=release and -X sun-panel/global.ISDOCKER=docker. Those two linker flags are how the binary knows it is running in the documented container mode rather than from a source checkout. On first start the Dockerfile runs ./sun-panel -config, which the image executes during build to generate initial configuration before the container's CMD ./sun-panel takes over.

Persistence is handled with three bind mounts in the compose file: /app/conf for configuration, /app/uploads for uploaded files, and /app/database for the data store. A fourth path, /app/runtime, appears in the compose file as a commented-out line. The README states the project does not need an external database, so the database directory is where its own storage lives. If you deploy without those mounts, the container will start but you should expect to lose configuration and data when it is recreated, since nothing is written outside the container filesystem.

Installing Sun-Panel with Docker Compose

The README points to a deployment tutorial on the documentation site rather than repeating the steps, but the repository ships a docker-compose.yml that is usable as-is. It pulls the image hslr/sun-panel:latest, names the container sun-panel, mounts the three directories next to the compose file, and publishes port 3002. The restart policy is always, so the panel comes back after a reboot.

version: "3.2"

services:
  sun-panel:
    image: 'hslr/sun-panel:latest'
    container_name: sun-panel
    volumes:
    - ./conf:/app/conf
    - ./uploads:/app/uploads
    - ./database:/app/database
    ports:
    - 3002:3002
    restart: always

Save that file, then start the stack from the directory containing it. The -d flag runs it in the background.

docker compose up -d

After the container starts, open http://<host>:3002 in a browser. The README does not document the default credentials in the text provided here, so check the documentation site for the first-login step. The Dockerfile exposes 3002, which is the only port the image declares, so there is no separate API port to open.

The compose file also lists ./runtime:/app/runtime as a commented line. If you enable it, the mount follows the same pattern as the other three. The image is published on Docker Hub as hslr/sun-panel, and the README notes Docker deployment is compatible with Arm systems, which covers Raspberry Pi boards and many NAS devices.

The closed-source notice is the first thing to read

The most important limitation is not technical. The README carries an important notice stating that the author added PRO features and that the project temporarily entered a closed-source state. It says the latest open-source version is v1.3.0, and points to the releases page for the latest closed-source version. The notice also says the plan is to separate the PRO code from the main program once modularization is developed, and that the closed-source period has no effect on ordinary users.

For an adoption decision this creates a gap between what the repository contains and what the image ships. The repository's master branch is the source you can read, but the compose file pulls hslr/sun-panel:latest, which according to the README corresponds to a newer, closed-source build. If your reason for choosing a self-hosted panel is that you can audit the code you run, the latest image does not satisfy that. The v1.3.0 tag does. That is a real trade-off and the README states it plainly rather than hiding it, which is worth noting, but it does not make the two things equivalent.

The release list shows v1.8.1 dated 2025-12-31, preceded by two beta tags in December 2025. The last push to the repository was on 2026-09-17. Those dates describe repository activity, not a maintenance promise, and the README does not document a support window or a deprecation policy.

Where Sun-Panel is the wrong tool

Sun-Panel is a navigation layer, not a monitoring system, not a reverse proxy, and not an authentication gateway. It can display system status, but the README does not describe alerting, historical metrics, or thresholds. If your actual problem is knowing when a disk fills up or a service goes down, a panel that shows a current number on a page you have to open is not the answer.

It also does not replace authentication in front of the services it links to. Multi-account isolation is listed as a feature of the panel itself, which the README describes as isolating accounts within Sun-Panel. It does not say the panel proxies the services behind those links, so a link to an admin interface still points at that interface, with whatever authentication that service has. Treat the panel as a directory, not as a gate.

The small-window feature is another case with a stated boundary. The README lists support for opening small windows in the webpage and adds that some third-party websites may block this feature. Sites that send X-Frame-Options or a frame-ancestors policy will refuse to render inside the panel, and nothing in the project can change that. If embedded windows are the reason you are evaluating it, test against your specific targets first.

Finally, there is no documented path to install Sun-Panel without Docker. The README's deployment section links to a tutorial, the Dockerfile produces a container, and the compose file is the deployment artifact in the repository. A source build is implied by the Dockerfile stages, but the README does not present it as a supported route.

How it compares with Homepage and Dashy

The obvious alternatives are Homepage and Dashy, both of which occupy the same slot: a self-hosted start page for a homelab. The difference is in how the page gets its content. Homepage is built around service integrations and widgets, so a card for a media server can show current activity pulled from that service's API, and the configuration lives in YAML files you edit by hand. Dashy leans on a configuration file as well, with a broad set of themes and status checks driven by that file.

Sun-Panel takes the opposite approach. Its README emphasizes visual operation and zero-code usage, and the front end includes drag-and-drop libraries (vuedraggable and vue-draggable-plus) in its dependencies. The intended workflow is arranging icons and groups in the browser, with the result stored in the panel's own database rather than in a file you version alongside your other config. That is faster to set up and easier for someone who does not want to edit YAML. It is also harder to review in a pull request and harder to rebuild from scratch if the database directory is lost.

The trade-off is concrete: if you want your start page defined as text in a git repository, Homepage or Dashy fits better. If you want to click and drag, Sun-Panel fits better. The closed-source notice adds a second axis, since Homepage and Dashy are not in that position, and that may matter more to some readers than the editing model.

Licence, upgrades and what to verify before you commit

The repository is MIT licensed. That covers the source in the repository. The README's notice about the closed-source state means the licence situation for the latest published image is not something this article can resolve, and it is not a legal question to answer here. If the licence of the binary you deploy matters to you, read the notice and the releases page, and decide whether the v1.3.0 tag is the version you want. Do not assume the MIT file at the repository root describes every build on Docker Hub.

Upgrade cost is low in the mechanical sense. The compose file pins the image tag latest, so docker compose pull followed by docker compose up -d moves you to the newest build. That convenience is also the risk: latest is not a fixed version, and the README does not document rollback or a migration path between versions. If you want reproducible upgrades, pin a specific tag instead of latest and change it deliberately. The release list shows both stable tags such as v1.8.1 and beta tags such as v1.8.1-beta251225, so there is a distinction to respect when pinning.

The repository includes a UPDATELOG.md at the top level, which is where version-to-version changes are recorded. Before upgrading across a large gap, read it. Before deploying at all, back up the ./database and ./conf directories, since those are the two mounts holding state. The third mount, ./uploads, holds uploaded files and belongs in the same backup set.

Editorial conclusion

Adopt Sun-Panel if you want a browser start page for a home server or NAS and you are comfortable running a container with three bind mounts. Avoid it if you need a fully open-source codebase for every release you deploy, or if you need the project to be installable from a package manager rather than Docker. Before deploying, read the README notice about the closed-source state and check which release you are actually pulling.

Frequently asked questions

Official sources

1. hslr-s/sun-panel on GitHub
2. License: MIT
3. Project website
4. README
5. Releases