Skip to main content

Admin Panel

The PCS Settings panel (also called the Admin Panel) is a web-based dashboard where you manage every aspect of your Personal Cloud Server. You can access it at https://admin-<yourdomain>.nsl.sh/ — for example, if your PCS domain is demo.nsl.sh, the admin panel is at https://admin-demo.nsl.sh/.

Logging In​

  1. Navigate to your admin panel URL (e.g. https://admin-demo.nsl.sh/).
  2. Click Single Sign-On.
  3. You'll be redirected to the Dex authentication page. Choose your identity provider — typically Log in with CasaOS.
  4. Enter the username and password you set up when you first configured your PCS, then click Login.

After authentication you'll be redirected back to the admin panel's Dashboard.

tip

The admin panel uses the same SSO system as all your other PCS apps. If you're already logged into another app, you may be signed in automatically.

Dashboard​

The Dashboard is the landing page of the admin panel. It provides a brief overview of what you can do:

Manage your domain updates, monitor server health, check PCS status, and update core information.

The left sidebar lists all available sections. You can collapse it with the arrow button at the bottom to get more screen space. The top bar includes:

  • Profile button — view your logged-in account
  • Language selector — switch the interface between English, French, Korean, and other available languages

System Information​

This page shows your PCS configuration at a glance. All fields are read-only — they reflect the values set during initial provisioning.

FieldWhat it shows
PasswordThe system-level password (hidden by default — click the eye icon to reveal it)
DomainYour PCS domain, e.g. demo.nsl.sh
ProviderThe NSL.SH provider connection string that links your PCS to the Yundera network
User IDYour unique Yundera user identifier
Default UserThe initial username and password created during setup (e.g. demo:demodemo)
Public IPThe public IP address where your PCS is reachable from the internet

This page is useful when you need to look up your PCS details for troubleshooting, or to share your domain/IP with a colleague.

Power​

The Reboot host button at the bottom performs a full system reboot via SSH. Use it when:

  • The PCS becomes unresponsive and apps won't restart normally
  • You've made a low-level configuration change that requires a reboot (e.g. kernel or network changes)
  • Docker or the container runtime is stuck
warning

Rebooting shuts down all running apps and services temporarily. Users accessing your apps will see errors until the PCS finishes booting. Only reboot when other options (restarting individual apps, running a self-check) haven't resolved the issue.

Account​

Your PCS credentials are managed by CasaOS, which acts as the identity provider. This page simply links you to the CasaOS dashboard where you can:

  • Change your password
  • Update your display name or profile
  • Manage other account settings

Click Open CasaOS dashboard to go there directly.

Domain​

The Domain page is where you control how your PCS is accessed from the internet. It has three main sections.

Your PCS Domain​

A summary of your current networking setup:

  • PCS Domain — Your main domain (e.g. demo.nsl.sh). This is what users type in the browser to reach your PCS.
  • Default Application — The container that currently serves your root domain (e.g. casaos:8080).
  • SSLIP.IO Domain — A fallback domain based on your IP address (e.g. 169-58-42-143.sslip.io). This always works even if your NSL.SH domain has issues.
  • Public IP — Your server's public-facing IP address.

Default Application​

This is one of the most powerful features. It controls which app opens when someone visits your root domain.

By default, visiting demo.nsl.sh opens the CasaOS dashboard. But you can change this to any running container. For example:

  • Select Docusaurus → now demo.nsl.sh opens your documentation site
  • Select Jellyfin → now demo.nsl.sh opens your media server
  • Select Immich → now demo.nsl.sh opens your photo gallery

This lets you present any app as the "front page" of your PCS, which is especially useful if you want to share a specific service publicly.

How to change it:

  1. Click the Container dropdown — it lists every running Docker container on your PCS.
  2. Select the container you want as your default app.
  3. Select the correct Port that the container exposes (most apps only expose one, so this is auto-filled).
  4. Click Save & apply.

The admin panel triggers a self-check that reloads the router, and within seconds your root domain will serve the newly selected app. If the container list seems outdated, click Refresh container list first.

tip

All your other apps remain accessible at their own subdomains (e.g. jellyfin-demo.nsl.sh, immich-demo.nsl.sh). Changing the default application only affects what happens when you visit the root domain without a subdomain prefix.

Use a Custom Domain​

If you own a domain (e.g. mycloud.example.com), you can point it to your PCS so users access your services through a professional URL instead of the .nsl.sh subdomain.

Cloudflare provides free DNS hosting with DDoS protection and hides your origin IP:

  1. Add your domain to Cloudflare — sign up at cloudflare.com, add your domain, and update your registrar's nameservers to Cloudflare's.
  2. Create a CNAME record — in Cloudflare DNS, add a CNAME record:
    • Name: your domain or subdomain (e.g. cloud for cloud.example.com)
    • Target: your sslip.io address (e.g. 169-58-42-143.sslip.io)
  3. Enable Proxy mode (orange cloud icon) — this makes Cloudflare terminate HTTPS and hide your real IP from visitors.
  4. Set SSL/TLS mode — go to SSL/TLS settings and choose Full or Full (strict) so Cloudflare talks to your PCS over HTTPS.

Direct DNS (Alternative)​

If you don't want to use Cloudflare:

  1. In your domain's DNS settings, add an A record pointing to your PCS public IP (e.g. 169.58.42.143).
  2. You'll need to handle HTTPS certificates yourself — your PCS doesn't automatically provision Let's Encrypt certificates for custom domains not going through Cloudflare.

Certificates​

Every app on your PCS gets its own subdomain (e.g. jellyfin-demo.nsl.sh), and each subdomain needs a valid TLS certificate for HTTPS. Caddy (the web server built into your PCS) handles this automatically.

This page shows the certificate status for all your .sslip.io domains.

Summary​

Four counters give you an instant overview:

  • Domains — total number of sslip.io subdomains detected
  • Let's Encrypt — domains with a valid, publicly trusted certificate (ideal)
  • Internal CA — domains using Yundera's self-signed fallback certificate
  • No Response — domains where the certificate check couldn't connect

What to do if you see "Internal CA"​

An Internal CA result on a .sslip.io domain means Caddy couldn't obtain a Let's Encrypt certificate. Common causes:

  • Rate limits — Let's Encrypt has issuance rate limits. Wait a few hours and check again.
  • DNS propagation — the sslip.io domain might not be resolving to your IP yet.
  • Port 443 blocked — your ISP or firewall may be blocking inbound HTTPS. Let's Encrypt needs to reach port 443 to verify your domain.

Browsers will show a security warning for internal CA certificates. The connection is still encrypted, just not publicly trusted.

note

Gateway routes (your .nsl.sh domain) and .nip.io routes intentionally use Yundera's internal CA — this is by design, not an error. Only .sslip.io domains use Let's Encrypt.

Access​

This page manages who can SSH into your PCS host machine.

Support Access​

This toggle controls whether Yundera support staff can SSH into your PCS using the orchestrator's support key. When you need help from Yundera:

  1. Enable this toggle — a support key is installed on the admin account.
  2. Contact support (via the Support page) and let them investigate.
  3. When done, disable the toggle — the key is removed immediately.

The setting is durable: a periodic self-check re-asserts it, so the key won't be silently lost if someone manually edits the SSH authorized_keys file or the system image refreshes.

Host Accounts & SSH Keys​

Shows all user accounts on the host system and their associated SSH public keys. This is useful for auditing who has SSH access. Click Refresh to re-read from the system.

Recent Login History​

A log of recent SSH login attempts (successful and failed), pulled from the system's auth logs. Useful for:

  • Checking if someone has been trying to brute-force SSH access
  • Verifying that support access was used only during the expected time window
  • Confirming that your own SSH sessions connected successfully

Terminal​

A web-based SSH terminal that runs directly in your browser — no SSH client needed.

Click Connect to start an interactive shell as the admin user on the host system. This is a full sudoer account, so you can run any command including:

  • docker ps — list running containers
  • docker logs <container> — view app logs
  • sudo systemctl restart docker — restart Docker
  • df -h — check disk space
  • htop — monitor processes in real-time

The session ends when you close the page or navigate away. It does not persist in the background.

tip

The terminal is invaluable for troubleshooting issues that can't be resolved through the admin panel GUI — for example, checking why a container won't start, manually editing a config file, or inspecting network connectivity.

warning

Since this shell has full sudo access, be careful with destructive commands like rm -rf, docker system prune, or anything that modifies /DATA. There is no undo.

Health​

The Health page monitors your PCS's update system and overall software status.

Update Channel​

Your PCS can receive updates from different channels:

  • Stable (default, recommended) — production-ready updates that have been thoroughly tested
  • Other channels (e.g. beta, nightly) may be available for advanced users who want early access to new features

Select a channel and click Save Channel to switch. The change takes effect on the next nightly run.

System Status​

Shows whether your PCS software is up to date and when the last maintenance run occurred.

Nightly schedule (cron) — Your PCS runs a maintenance job every night that:

  • Checks for and applies software updates
  • Renews TLS certificates
  • Runs health checks on all services
  • Cleans up unused Docker images and resources

The default schedule is 0 3 * * * (3:00 AM daily). You can:

  • Leave it blank to use the default
  • Enter a custom cron expression (e.g. 0 5 * * * for 5 AM)
  • Set to disabled to skip nightly runs entirely (not recommended — your PCS may miss important updates)

The @reboot run is always installed regardless, so your PCS self-heals after any restart.

Click Run now to trigger an immediate maintenance run — useful after changing the update channel or if you want to force an update check.

Log Tail​

Shows the most recent lines from the system log (yundera.log). Useful for:

  • Checking if the nightly maintenance ran successfully
  • Diagnosing update failures
  • Seeing what the self-check did on last boot

Apps​

The Apps page gives you a unified view of everything installed on your PCS, including their data and backups.

Summary​

Four counters at the top:

  • Live — apps currently running and accessible
  • Down — apps that are installed but stopped
  • Backups — number of backup zip archives found under /DATA/AppData
  • Issues — apps with configuration or health problems

What You Can Do​

For each installed app, you can:

  • View details — see which Docker image it uses, its data folder path, and status
  • Start / Stop — bring an app up or take it down without uninstalling it. Useful for saving resources when you're not using an app.
  • Backup — creates a zip archive of the app's data folder. The backup is stored under /DATA/AppData and can be downloaded or restored later.
  • Restore — restore an app from a previous backup zip. This replaces the app's current data with the backup.

All of this happens without leaving the page — no SSH or command-line needed.

Click Refresh to re-scan for apps, data folders, and backups.

tip

Before making major changes to an app's configuration, it's good practice to create a backup first from this page. If something goes wrong, you can restore to the previous state in seconds.

Resources​

Real-time hardware monitoring for your PCS, split into three tabs.

CPU Tab​

  • CPU usage — current usage as a percentage across all cores
  • Cores & uptime — how many CPU cores the PCS has and how long it's been running since last boot
  • Load average — system load over 1, 5, and 15 minutes. A load average at or below the number of cores means the system is comfortable. Above that, it's overloaded.
  • Memory — RAM usage (used / total) and swap usage. If swap is heavily used, your PCS may need more RAM.
  • Top processes — the 10 most resource-hungry processes, sorted by CPU usage. Helpful for identifying which app is consuming the most resources.

Network Tab​

  • Download / Upload speed — current throughput and total data transferred since boot on each network interface (typically eth0)
  • Network speed test — measures your PCS's actual internet bandwidth by downloading/uploading test data. Results show download speed, upload speed, and latency.
note

The speed test temporarily uses your internet bandwidth. Avoid running it while users are actively using bandwidth-heavy apps like media streaming.

Disk Tab​

  • Read / Write speed — current I/O throughput per physical disk
  • Filesystems — shows each mounted partition with used space, total space, and usage percentage. Watch the root / filesystem — if it gets above 90%, you should free up space or expand the disk.
  • Disk benchmark — measures sequential read/write performance of your disk. Useful for comparing against expected specs or diagnosing slow storage.
note

The disk benchmark saturates I/O while running. Don't run it when apps are serving users — it will cause everything to slow down temporarily.

Migration​

Migration lets you move your entire PCS — domain, all apps, all data — from one physical machine to another. This is useful when:

  • You're upgrading to a more powerful server
  • You're moving from a home setup to a data center (or vice versa)
  • Your current hardware is failing and you need to relocate

The key principle: the source PCS (where your data currently lives) does all the work. The destination (the new machine) just needs SSH access and a sudoer account. It can even be a bare Ubuntu server — Docker will be installed automatically during migration.

Step-by-Step Guide​

1. Prepare the Destination (New Machine)​

On the new PCS's admin panel, go to Migration and find Migrate INTO this PCS:

  1. Click Enable — this creates a temporary sudoer account called migration with a random password.
  2. Note down the credentials shown.
  3. Enter the source PCS URL and click Open source migration panel — this opens the source PCS's migration page with the destination pre-filled.

2. Start Migration from the Source (Current PCS)​

On this PCS (the one being moved), find Migrate OUT of this PCS:

  1. Fill in the destination details:
    • Destination host or IP — the new machine's address
    • Destination migration user — usually migration (created in step 1)
    • Destination migration password — the random password shown on the destination
    • Webhook URL (optional) — an HTTPS endpoint to receive status updates
  2. Click Test connection — verifies SSH connectivity to the destination.
  3. Click Start migration — begins the automated 13-step pipeline.

The 13-Step Pipeline​

The migration is fully automated. Here's what happens at each step:

StepWhat happensYour apps
1. Preflight checksVerifies the destination is reachable, has enough disk space, and clocks are in syncRunning
2. Install SSH keySets up secure key-based authentication between source and destinationRunning
3. Online rsyncCopies all of /DATA to the destination. This is the longest step — it depends on how much data you have (could be minutes or hours). Your apps keep running during this.Running
4. Pull Docker imagesDownloads all app images on the destination so they're ready to start instantlyRunning
5. Stop appsStops all apps on the source and disables the self-check cron. Brief downtime starts here.Down
6. Offline diff rsyncA fast second sync that copies only files that changed since step 3Down
7. Self-check on destinationThe new PCS installs Docker (if needed), detects its public IP, and sets up its identityDown
8. Start apps on destinationAll your apps come up on the new machineStarting
9. Deregister sourceThe old PCS stops its network router — the domain switches to the new machineSwitched
10. Verify destinationConfirms the new PCS is healthy and serving the domain correctly. If this fails, migration rolls back.Running (new)
11. Revoke migration accessRemoves the temporary SSH key from the destinationRunning (new)
12. Source shutdownSchedules the old PCS's admin to shut downRunning (new)
13. Signal orchestratorNotifies Yundera that migration is completeRunning (new)
warning

The downtime window (steps 5–9) is typically brief — just long enough for the final diff sync and DNS switchover. But plan for it: notify your users and avoid migrating during peak usage hours.

tip

After migration, don't forget to disable the migration account on the destination PCS. Go to Migration → Migrate INTO this PCS → click Disable.

Billing​

Billing isn't managed in the admin panel directly. Click Go to Yundera Dashboard to open app.yundera.com/dashboard where you can:

  • View your current subscription plan
  • Update payment methods
  • See billing history and invoices
  • Upgrade or downgrade your plan

Support​

Two features to get help when you need it.

Yundera Support SSH Access​

This toggle allows Yundera support engineers to SSH into your PCS to diagnose issues directly. How it works:

  • Enable → a support SSH key is installed on the admin account. Yundera staff can log in to investigate.
  • Disable → the key is removed immediately. No one from Yundera can access your machine.

The setting is durable — a periodic self-check re-asserts it, so the key won't be accidentally lost. But you can revoke it anytime and the removal is instant.

Contact Support​

Send a support ticket directly from the admin panel:

  1. Subject — a brief summary of your issue.
  2. Describe the issue — detailed description (up to 10,000 characters). Include what you were doing, what you expected, and what actually happened.
  3. Attach yundera.log (checked by default) — sends the last 5,000 lines of the system log, gzipped. This gives the support team context about recent system activity without you having to manually dig through logs.
  4. Grant SSH access (optional) — checking this automatically enables the Support SSH toggle above, so the support team can investigate your PCS directly. You can revoke it anytime from the Access or Support page.
  5. Click Send to support.
tip

Attaching the log and granting SSH access dramatically speeds up issue resolution. The support team can see exactly what's happening on your system instead of going back and forth asking for information.